Closed Bug 645914 Opened 9 years ago Closed 9 years ago

Highlighting last word of a line with double click will highlight newline character of it

Categories

(Core :: DOM: Editor, enhancement)

All
Windows 7
enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: ebrahim, Assigned: ehsan)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 

Hi, selecting text with double click is a bit different with IE, Chrome and Text Editors programs. When you select last word of a line in textarea (with double click) and remove that word with "Delete Button", you will see newline character is deleted with it. I think making compatible behavior with text editors is a good reason for changing Firefox method. I selected enhancement severity for this.

Reproducible: Always

Steps to Reproduce:
1. Open provided URL
2. Highlight "Three" with double click on it

There is two way:
3.1: Delete highlighted string using "Delete key", you will see "Four" coming to first line. (it is so easy to compare this behavior on other browser and text editor with Firefox)
3.2: Encoded text of highlighted part will shown in bottom. "Three%0A" is wrong and you can not see it in Chrome
Regression Range :
works:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100913 Firefox/4.0b6pre
broken:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre
pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=84ee6bc0484d&tochange=5588c9796f0b
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 240933
Keywords: regression
I couldn't reproduce this on Mac, but it's easily reproducible on Windows.
selectionEnd is 14 on Windows.  I'm suspecting that the windows line ending stuff is in play here.
OS: All → Windows 7
Attached patch Patch (v1)Splinter Review
Arguably this has always been broken, it was just exposed with my patch.

What happens is that when we're trying to jump to the end of the word in nsIFrame::PeekOffset, if the eat_whitespace pref is true, and we reach the end of a line, we do not check if nsTextFrame::GetFrameFromDirection has eaten the newline as a white-space at the end of the line.  This patch fixes that.

When creating the test, I thought that it wouldn't be a terrible idea to test some basics for line selection and paragraph selection too...
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #522862 - Flags: review?(roc)
http://hg.mozilla.org/mozilla-central/rev/cbb7ffa045d3
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
You need to log in before you can comment on or make changes to this bug.