0004512: Editor generates unsupported/invalid font size values

(0013263)
Nibogo (Team Member)
2010-10-21 00:10

Again, this is an issue with WebKit not only with Chrome.

Attached a patch.

(0013274)
Norv (Developer)
2010-10-21 17:39
edited on: 2010-10-21 17:51

it still remains true this way, that:
- enable WYSIWYG
- write a test word
- set a big size on it
- disable WYSIWYG / enable WYSIWG ==> you don't get the initial word back

(0013276)
Nibogo (Team Member)
2010-10-21 20:45
edited on: 2010-10-21 20:45

Sorry Norv, didn't noticed that, I just attached another patch, I just moved the same code to the html_to_bbc function.

(0013427)
GravuTrad (Team Member)
2010-11-23 07:38

I confirm the bug for webkit (safari, firefox etc...)

(0013447)
Norv (Developer)
2010-11-24 08:24
edited on: 2010-11-24 08:59

(0013448)
[SiNaN] (Developer)
2010-11-24 09:48

Attached patch looks too hacky to go into core I think.

The other one would fix the first two, but it won't deal with the third "-webkit-xxx-large". This one might be better for that regex though, to prevent output like xx-larger (it's invalid):

'test' => '([1-9][\d]?p[xt]|small(?:er)?|large[r]?|x[x]?-(?:small|large)|medium|(0\.[1-9]|[1-9](\.[\d][\d]?)?)?em)\]',

(still doesn't fix the third case though - I don't think you can fix it with this regex)

(0013449)
Norv (Developer)
2010-11-24 10:28

Looking good.

-webkit-xxx-larger should be handled by the editor itself I think.

(0013612)
Nibogo (Team Member)
2011-01-21 11:35

Sinan's fix was commited and it's working pretty well, but there is still the issue with -webkit-xxx-larger, as Norv said that could be easily fixed from editor's side, those worked pretty well for me: (Both in Subs-Editor.php)

Search:

$text = preg_replace(array('~<div(?:\s(?:[^<>]*?))?' . '>~i', '</div>'), array('
', ''), $text);

Replace with:

$text = preg_replace(array('~<div(?:\s(?:[^<>]*?))?' . '>~i', '</div>', '~<span\s+[^<>]*? style="font-size: -webkit-xxx-large;">(.*?)</span>~i'), array('
', '', '<span style="font-size: 36pt;" class="bbc_size">$1</span>'), $text);

--- or ---

Search:

$curCloseTags .= '[/size]';

Replace with:

if ($context['browser']['is_webkit'])
$style_value = str_replace('-webkit-xxx-large', '36pt', $style_value);

$curCloseTags .= '[/size]';

Hope it helps

(0014479)
Spuds (Developer)
2012-03-04 20:55

Unable to reproduce the webkit-xxx-large issue with the latest version of chrome. Looks like webkit made changes to execCommand back in early 2011 to fix this issue. I don't think there is anything left to do here unless someone else is seeing this issue in a recent browser.

News:

Simple Machines Bug and Feature Tracker

Notes
(0013263) Nibogo (Team Member) 2010-10-21 00:10	Again, this is an issue with WebKit not only with Chrome. Attached a patch.

(0013274) Norv (Developer) 2010-10-21 17:39 edited on: 2010-10-21 17:51	it still remains true this way, that: - enable WYSIWYG - write a test word - set a big size on it - disable WYSIWYG / enable WYSIWG ==> you don't get the initial word back

(0013276) Nibogo (Team Member) 2010-10-21 20:45 edited on: 2010-10-21 20:45	Sorry Norv, didn't noticed that, I just attached another patch, I just moved the same code to the html_to_bbc function.

(0013427) GravuTrad (Team Member) 2010-11-23 07:38	I confirm the bug for webkit (safari, firefox etc...)

(0013447) Norv (Developer) 2010-11-24 08:24 edited on: 2010-11-24 08:59	How about the fix, Gravu? Or, how about this: (Subs.php) find 'test' => '([1-9][\d]?p[xt]\|(?:x-)?small(?:er)?\|(?:x-)?large[r]?\|(0\.[1-9]\|[1-9](\.[\d][\d]?)?)?em)\]', replace with 'test' => '([1-9][\d]?p[xt]\|(?:x-)?small(?:er)?\|medium\|(?:x-)?large[r]?\|xx-large\|(0\.[1-9]\|[1-9](\.[\d][\d]?)?)?em)\]',

(0013448) [SiNaN] (Developer) 2010-11-24 09:48	Attached patch looks too hacky to go into core I think. The other one would fix the first two, but it won't deal with the third "-webkit-xxx-large". This one might be better for that regex though, to prevent output like xx-larger (it's invalid): 'test' => '([1-9][\d]?p[xt]\|small(?:er)?\|large[r]?\|x[x]?-(?:small\|large)\|medium\|(0\.[1-9]\|[1-9](\.[\d][\d]?)?)?em)\]', (still doesn't fix the third case though - I don't think you can fix it with this regex)

(0013449) Norv (Developer) 2010-11-24 10:28	Looking good. -webkit-xxx-larger should be handled by the editor itself I think.

(0013612) Nibogo (Team Member) 2011-01-21 11:35	Sinan's fix was commited and it's working pretty well, but there is still the issue with -webkit-xxx-larger, as Norv said that could be easily fixed from editor's side, those worked pretty well for me: (Both in Subs-Editor.php) Search: $text = preg_replace(array('~<div(?:\s(?:[^<>]?))?' . '>~i', '</div>'), array(' ', ''), $text); Replace with: $text = preg_replace(array('~<div(?:\s(?:[^<>]?))?' . '>~i', '</div>', '~<span\s+[^<>]? style="font-size: -webkit-xxx-large;">(.?)</span>~i'), array(' ', '', '<span style="font-size: 36pt;" class="bbc_size">$1</span>'), $text); --- or --- Search: $curCloseTags .= '[/size]'; Replace with: if ($context['browser']['is_webkit']) $style_value = str_replace('-webkit-xxx-large', '36pt', $style_value); $curCloseTags .= '[/size]'; Hope it helps

(0014479) Spuds (Developer) 2012-03-04 20:55	Unable to reproduce the webkit-xxx-large issue with the latest version of chrome. Looks like webkit made changes to execCommand back in early 2011 to fix this issue. I don't think there is anything left to do here unless someone else is seeing this issue in a recent browser.

Relationships