Last Comment Bug 437672 - iframe.contentDocument.getSelection() reports selection when nothing is if BR element is on the line
: iframe.contentDocument.getSelection() reports selection when nothing is if BR...
Status: RESOLVED INVALID
: regression
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 1.9.0 Branch
: All All
-- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
http://xinha.gogo.co.nz/xinha-nightly...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-06 12:39 PDT by Douglas Mayle
Modified: 2009-01-22 11:46 PST (History)
6 users (show)
jst: wanted1.9.1-
mbeltzner: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Douglas Mayle 2008-06-06 12:39:12 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en_US; rv:1.9) Gecko/2008051909 (Gentoo) Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en_US; rv:1.9) Gecko/2008051909 (Gentoo) Firefox/3.0

In Firefox 3 (tested in RC1 and RC2 on mac and linux, didn't exist in FF2), the getSelection function is returning from cursor to the end of the page as a selection, even when nothing is selected

Reproducible: Always

Steps to Reproduce:
1.Go to URL http://xinha.gogo.co.nz/xinha-nightly/examples/ExtendedDemo.html
2. Go to HTML source view of Xinha (click the third icon from the right, looks like a page with angle brackets)
3. Paste the following HTML "General Resources<br /> 
<h3>mailing lists</h3>"
4. Go back to document view (re-click the same icon)
5. Now click the end of the first line and hit the enter key.  The text of the second line will disapper.

Actual Results:  
The second line has disappeared, since getselection reports a selection to the end of the iframe

Expected Results:  
an inserted line, becuase there is no selection


This happens because a getSelection is performed to see if the user is attempting to replace text, which is reporting a selection starting at the cursor and continuing to the end of the iframe.  That select is then replace with a newline (the enter key) and so the line disappears.  In Firefox 2, javascript correctly reports an empty selection
Comment 1 User image Mike Beltzner [:beltzner, not reading bugmail] 2008-06-09 22:35:28 PDT
--> Core::DOM
Comment 2 User image Mike Beltzner [:beltzner, not reading bugmail] 2008-06-09 22:35:56 PDT
This will not block the final release of Firefox 3.0. A patch with tests may be considered for a 3.0.x release.
Comment 3 User image Douglas Mayle 2008-06-11 11:53:27 PDT
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
Comment 4 User image Mike Beltzner [:beltzner, not reading bugmail] 2008-06-24 18:37:46 PDT
bent: any ideas?
Comment 5 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2008-06-24 19:40:18 PDT
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?
Comment 6 User image Douglas Mayle 2008-06-25 10:34:59 PDT
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...
Comment 7 User image Johnny Stenback (:jst, jst@mozilla.com) 2008-07-09 15:09:35 PDT
Not wanted for 1.9.1, but if this turns out to really be a bug that needs fixing, patches would still be considered.
Comment 8 User image Douglas Mayle 2009-01-22 11:46:41 PST
After much time, I'm still unable to understand the original javascript code that breaks.  Careful examination of the C code that changed between the working and non-working versions above shows that the change was desired, and fixed a bug in firefox's implementation of a standardized API.  I've completely replaced the buggy and unreadable code with a well documented implementation that makes sense.  The fault lies in the ugly code that depended on a broken implementation in order to work.  I'm closing this 'invalid'.

Note You need to log in before you can comment on or make changes to this bug.