Advertisement:

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004512SMF 2.1[SMF 2.0] Generalpublic2010-10-20 03:282012-08-14 09:39
Reporter[SiNaN] 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0004512: Editor generates unsupported/invalid font size values
DescriptionOnly in Chrome on WYSIWYG mode (doesn't happen with plain editor), editor assigns unsupported/invalid font size values. These are:

1) medium
2) xx-large
3) -webkit-xxx-large

First two can be supported by changing size BBC. However, a different solution will be required for third type.
Steps To Reproduce1) Write something.
2) Set the font size as 24pt or 36pt.
3) Submit the post.
Additional InformationTested on Chrome 7 with WYSIWYG mode on using rev 10187.
Tags2.1, With Fix, WYSIWYG
Attached Filespatch file icon 4512.patch [^] (876 bytes) 2010-10-21 20:44 [Show Content]

- Relationships

-  Notes
(0013263)
Nibogo (SMF Friend)
2010-10-21 00:10

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

Attached a patch.
(0013274)
Norv (SMF Friend)
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 (SMF Friend)
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 (SMF Friend)
2010-11-23 07:38

I confirm the bug for webkit (safari, firefox etc...)
(0013447)
Norv (SMF Friend)
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] (SMF Friend)
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 (SMF Friend)
2010-11-24 10:28

Looking good.

-webkit-xxx-larger should be handled by the editor itself I think.
(0013612)
Nibogo (SMF Friend)
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 (SMF Friend)
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.
MantisBT 1.2.8 (Modified)[^] Copyright © 2000 - 2010 Mantis Group