Anonymous Login
06-19-2018 07:43 PM

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004512SMF 2.1[SMF 2.0] Generalpublic2012-08-14 09:39
PrioritynormalSeverityminorReproducibilityhave not tried
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 Files
  • patch file icon 4512.patch (876 bytes) 2010-10-21 20:44 -
    Index: Sources/Subs-Editor.php
    --- Sources/Subs-Editor.php	(revision 10171)
    +++ Sources/Subs-Editor.php	(working copy)
    @@ -516,6 +516,10 @@
     		// Put the tags back into the body.
     		$text = substr($text, 0, $start_pos) . $before . $content . $after . substr($text, $end_pos + 7);
    +	// Fix issue with WebKit and WYSIWYG
    +	if ($context['browser']['is_webkit'])
    +          $text = preg_replace('~\[size=(x-small|small|medium|large|x-large|xx-large|-webkit-xxx-large)\]~ie', '\'[size=\' . strtr(\'$1\', array(\'x-small\' => \'8\', \'small\' => \'10\', \'medium\' => \'12\', \'large\' => \'14\', \'x-large\' => \'18\', \'xx-large\' => \'24\', \'-webkit-xxx-large\' => \'36\')) . \'pt]\'', $text);
     	// Almost there, just a little more time.
     	if (connection_aborted() && $context['server']['is_apache'])
    patch file icon 4512.patch (876 bytes) 2010-10-21 20:44 +




Nibogo (Viewer)

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

Attached a patch.


Norv (SMF Friend)

Last edited: 2010-10-21 17:51

View 1 revisions

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


Nibogo (Viewer)

Last edited: 2010-10-21 20:45

View 2 revisions

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


GravuTrad (Viewer)

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


Norv (SMF Friend)

Last edited: 2010-11-24 08:59

View 2 revisions

How about the fix, Gravu?
Or, how about this: (Subs.php)

'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)\]',


[SiNaN] (Viewer)

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)


Norv (SMF Friend)

Looking good.

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


Nibogo (Viewer)

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)


$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 ---


$curCloseTags .= '[/size]';

Replace with:

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

$curCloseTags .= '[/size]';

Hope it helps


Spuds (Viewer)

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 (Modified for SMF Intergration)[^] Copyright © 2000 - 2010 Mantis Group