Severity: major → blocker
Version: unspecified → 3.0 Branch
Severity: blocker → major
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: 3.0 Branch → 1.9.0 Branch
This will not block the final release of Firefox 3.0. A patch with tests may be considered for a 3.0.x release.
Regression happened between the two nightly builds: WORKING -> 2006-10-21-06-trunk BROKEN -> 2006-10-22-05-trunk WORKING -> ftp://ftp.mozilla.org/pub/firefox/nightly/2006/10/2006-10-21-06-trunk/firefox-3.0a1.en-US.mac.dmg BROKEN -> ftp://ftp.mozilla.org/pub/firefox/nightly/2006/10/2006-10-22-05-trunk/firefox-3.0a1.en-US.mac.dmg
bent: any ideas?
Flags: blocking126.96.36.199? → wanted1.9.1?
The test case is WFM. I couldn't make anything funny happen no matter where I pasted that text. Douglas, could you clarify these steps any? Do I have to paste that text in a particular place?
I can reproduce the test case every time on many computers... You have to go to HTML mode before inserting the text, then return to document mode, but upon further inspection, the algorithm behind this page is so poorly written that I've come to believe it's miswritten, and is just dependent on the behavior pre-Firefox3, even if that behavior is wrong. I looked at the code differences in Firefox, and it's a change in nsRange.cpp which looks like it is a valid change (Before, trying to create a range in reverse resulted in an invalid range. Now, trying to create a range in reverse collapses the range... I see this as valid behavior, but I was hoping to wait till the end of the week to finish my testing...
Not wanted for 1.9.1, but if this turns out to really be a bug that needs fixing, patches would still be considered.
Flags: wanted1.9.1? → wanted1.9.1-
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.