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)

14 Branch
x86
Windows XP
defect
Not set
normal

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>
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...
(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/
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 :)
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/
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 !
In reward for your kindness => ExTrA BoNuS : test case ! https://doc.netsoins.org/firefox-fontsize.php
(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
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.
Did this use to work in older versions of Firefox?
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.
(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).
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.