Closed Bug 913315 Opened 7 years ago Closed 7 years ago
Index incorrect when <option> replaced dynamically via .inner HTML ....
Severity: normal → major
OS: Windows 8 → All
Hardware: x86_64 → All
This attached HTML demonstration is less than 50 lines long and specifically demonstrates the problem interfering with one of my websites. RELATED: This is causing major problems with one of my websites, http://www.testufo.com when running in FireFox. 1. Load http://www.testufo.com/#test=ghosting&dontreload=1 2. Play with "Background" color, it works. 3. Using top selector, change to "Blur Trail" 4. Play with "Background" color, it stops working in FireFox 24/25/26 (No problems in FF23 and prior, IE, Chrome, Opera) I view this as a potentially major bug that needs to be fixed before FireFox 24 becomes public release, as this is such a fundamental/simple AJAX technique creating incorrect results.
Tested on Windows & Mac. Same problem.
Adds an automated "Test for Bug" button.
I can reproduce on FX24, but m-c/nightly seems good. Has this been fixed recently? dup?
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Product: Firefox → Core
Hmm, it does seem to be fixed in Nightly. It wasn't fixed in FireFox 26 Nightly about two weeks ago, so there must be a different bug covering this. That said, the simplified HTML example above should show this bug is major enough that it should be fixed for FireFox 24 and FireFox 25. There must be at least other AJAX websites affected by this (and certain webmasters who has scratched their heads over this; like myself).
I cannot reproduce the problem in Nightly26.0a1. Fixed window(m-i) Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/6a5a7b55c22a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130809175542 Fixed: http://hg.mozilla.org/integration/mozilla-inbound/rev/29c341748a6b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130809193241 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6a5a7b55c22a&tochange=29c341748a6b I guess this is fixed by Bug 895758
Confirmed fixed in the latest 26 as well; it was problematic just a few weeks ago. Will the bugfix propagate to FireFox 24 on time before public release? Or will I have to design a workaround for my website to bypass this bug in the upcoming public FireFox 24?
Not very likely that bug 895758 will be backported... I'm surprised that we broke it, though. Alice, would you happen to have time to find a regression window too?
Severity: major → normal
(In reply to Avi Halachmi (:avih) from comment #5) > I can reproduce on FX24, but m-c/nightly seems good. Oops, I lied. I tested with FX23, and the testcase indicates it's broken on 23. The testcase comes up not-broken with nightly, and I haven't tested with 24.
(In reply to :Ms2ger from comment #9) > Not very likely that bug 895758 will be backported... I'm surprised that we > broke it, though. > > Alice, would you happen to have time to find a regression window too? I can reproduce the problem in Firefox1.0, 4.0.1, 17.0.8esr, 20.0.1 as well as Firefox23.0.1. So, I think this is not a recent regression. I do not understand "GOOD" version of comment#0.
I've tested several variants of TestUFO in older browsers and found good FireFox browsers (FireFox 23 had no problems). It must be a specific behaviour of the test-case-isolation demo file I creatred (test.html and firefox_bug_demo.html) that causes problems in more versions of FireFox. Let me investigate.
Summary: selectedIndex incorrect when <option> replaced dynamically via .innerHTML .... [WORKS: FF22/23 / BAD: FF24/25/26] → selectedIndex incorrect when <option> replaced dynamically via .innerHTML ....
OK, it was hard for me to isolate, so I am not sure what caused different behaviors. When I isolated the test cases to test.html it actually doesn't work properly in most versions of FireFox! I am surprised that this bug has existed for a very long time... WORKAROUND: Use different <option> id's even for dynamic replacement of <option> lists, so when dynamically replacing <option> lists, use a different ID. This means a workaround will need to be made in my site, but at least there's a workaround.
(In reply to Mark Rejhon from comment #12) > I've tested several variants of TestUFO in older browsers and found good > FireFox browsers (FireFox 23 had no problems). It must be a specific > behaviour of the test-case-isolation demo file I creatred (test.html and > firefox_bug_demo.html) that causes problems in more versions of FireFox. > Let me investigate. I think it would be useful if you could further isolate different variants of this issue, and especially the variant which works in 23 but is broken in 24. Seeing that we might add some docs on this issue, the current testcase variant which hasn't changed behavior in years would be less important than the variant which broke in 24.
The workaround has failed - it's not even dependent on ID's being the same. Any <option> elements that gets replaced by <option> elements (via replacing innerHTML) is broken in so many FireFox browsers, apparently. I spent a couple hours trying to test the workaround, so for now, I've inserted an ugly location.reload() to reload the whole page, whenever the useragent is FireFox of a version less than 26. As for the FireFox 23 specific situation, I'm having difficulty isolating the FireFox 23-specific issue, since I reproduced a scenario a few weeks ago but I can't seem to reproduce it now. I'm testing out what I did differently/specially.
A testcase that shows a problem in fx24 but not fx23 would be much appreciated. It doesn't have to be super-small; just needs to be able to show the problem in one but not the other.
:bz, is this a Fx24 specific regression ? Based on bug comments https://bugzilla.mozilla.org/show_bug.cgi?id=913315#c11, might be an old regression ? Given we are close to shipping Fx24 not sure we'd fix it in Fx24 unless this is a critical issue and we know if any websites are impacted. Is there a work around that we could recommend here ?
TestUFO.com is impacted, but I've already deployed a fix (forced page reload; sigh). I don't rate this a critical issue, albiet a major one (from my perspective). I'm quite intrigued/curious why this bug has lasted as long as it has. I imagine this has stymied more than one web designer, but didn't know how to isolate it.
I spent a couple hours trying: I confirm I have been unable to reproduce the test case that works on FF23 but fails on FF24. FF23 and FF24 has the same bug.
(In reply to bhavana bajaj [:bajaj] from comment #17) > :bz, is this a Fx24 specific regression ? Based on bug comments > https://bugzilla.mozilla.org/show_bug.cgi?id=913315#c11, might be an old > regression ? Given we are close to shipping Fx24 not sure we'd fix it in > Fx24 unless this is a critical issue and we know if any websites are > impacted. The bug for which we have a test case has existed for ages; nobody seems to have been able to find a test case that showed an actual regression; and a fix has been deployed to the site. I think we're fine.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 895758
You need to log in before you can comment on or make changes to this bug.