Closed
Bug 763859
Opened 13 years ago
Closed 13 years ago
execCommand('fontSize',false,6) while styleWithCss is enabled inserts <font size="6">
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: geompse, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
Steps to reproduce:
On a documentElement "docelm" properly configured for editing, with some text selected :
docelm.execCommand('styleWithCSS',false,true);
docelm.execCommand('fontSize',false,6);
Actual results:
<font size="6">MyText</font>
Expected results:
<span style="font-size:24pt;">MyText</span>
-or eventually-
<font style="font-size:24pt;">MyText</font>
Reporter | ||
Comment 1•13 years ago
|
||
FYI : Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0
(I was checking in Google Chrome)
Additionnal informations :
- This bug was NOT present in Firefox 11.0
- Also, reverts issue #480647
> if you have something like this :
<span style="font-size:12pt;">MyText</span>
> it will produce :
<font size="6"><span style="font-size:12pt;">MyText</span></font>
> then MyText font size stands at 12pt, not 24pt...
![]() |
||
Comment 2•13 years ago
|
||
(In reply to Tom Geompse from comment #1)
> - This bug was NOT present in Firefox 11.0
Can you find a Regression Range?
http://mozilla.github.com/mozregression/
Reporter | ||
Comment 3•13 years ago
|
||
Heeww... that's a little confusing :
BAD - Stable channel : Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0
GOOD - Latest nightly 2012-06-12
Does that mean that there is a bug in the stable version, but that it has been fixed on the latest nightly ?
Is there a way to know wich nightly matches the latest stable Firefox ?
With mozregression, dichotomy is used to test several version, so the bugged one is likely to be skipped.
I tried moznightly but it seems to be broken (this nightly loads correctly with mozregression) :
> Administrateur@WINDOWS-8519CCF ~
> $ moznightly --date=2012-06-12
>
> Downloading nightly from 2012-06-12
>
> Starting nightly
>
> Exception WindowsError: (5, 'Acc\xe8s refus', 'moznightlyapp\\firefox\\firefox.exe') in <bound method FirefoxNightly.__del__ of <mozregression.runnightly.FirefoxNightly object at 0x0
166BB30>> ignored
Anyway this tool is very neat, nice job :)
![]() |
||
Comment 4•13 years ago
|
||
If this really regressed after Version 11 you should use
mozregression --good=2011-12-20
since then 11 branched off to Aurora and Nightly became 12.
Would be nice to know if the Issue is present in
Nightly: http://nightly.mozilla.org/
Aurora: http://www.mozilla.org/en-US/firefox/aurora/
Beta: http://www.mozilla.org/en-US/firefox/beta/
Reporter | ||
Comment 5•13 years ago
|
||
BAD - beta
GOOD - aurora
GOOD - nightly
I could not find when the regression occured... because even in a nightly from august tagged 8.0 it is broken.
However, I hacked it looking for the fix instead of the regression, or the "regression making it work again" :)
> mozregression --good=2011-12-20 --bad=2012-06-14
It is like having the "mozcorrection" tool :
> mozcorrection --bad=2011-12-20 --good=2012-06-14
But the method with "mozregression" involve answering the opposite (when it works : bad, when it does not : good).
Anyway, here is when the fix occured :
BAD > Last good nightly: 2012-04-24
GOOD > First bad nightly: 2012-04-25
> Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=21da3f655b30&tochange=75c7378c87b6
I hope this will help !
Reporter | ||
Comment 6•13 years ago
|
||
In reward for your kindness => ExTrA BoNuS : test case !
https://doc.netsoins.org/firefox-fontsize.php
![]() |
||
Comment 7•13 years ago
|
||
(In reply to Tom Geompse from comment #5)
> Anyway, here is when the fix occured :
> BAD > Last good nightly: 2012-04-24
> GOOD > First bad nightly: 2012-04-25
> > Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=21da3f655b30&tochange=75c7378c87b6
Thanks. Based on that Range and that it works in Aurora (i.e. Firefox 15) and higher this can be resolved WFM since the Fix won't be uplifted to Beta (Firefox 14) but rather run the Release Train.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Component: Untriaged → Editor
Product: Firefox → Core
QA Contact: untriaged → editor
Resolution: --- → WORKSFORME
Version: 13 Branch → 14 Branch
Reporter | ||
Comment 8•13 years ago
|
||
Do you mean that no patch will be issued for 13 (i.e. 13.0.1) ?
Currently my customers are unable to change font-size in the wysiwyg editor.
Comment 9•13 years ago
|
||
Did this use to work in older versions of Firefox?
Reporter | ||
Comment 10•13 years ago
|
||
Giving to the nightlies, no.
This is weird because it used to work for at least the past 2 years, my customers used this every day.
Nevermind... it looks like Firefox 14 will fix everything
*joke* I believe someone evil altered all the previous versions, even those stored on my computer.
![]() |
||
Comment 11•13 years ago
|
||
(In reply to Tom Geompse from comment #10)
> Nevermind... it looks like Firefox 14 will fix everything
As I posted above the Fix is in 15 (Aurora now) - not 14. I verified that by comparing your Testcase with Beta (14) and Aurora (15).
Comment 12•9 years ago
|
||
it's back with <font> what's wrong? http://jsfiddle.net/crl/wfm8fbzu/1/
You need to log in
before you can comment on or make changes to this bug.
Description
•