selectionEnd off by one when user selects text via CMD/CTRL-A

RESOLVED FIXED in mozilla1.3beta

Status

()

P3
normal
RESOLVED FIXED
16 years ago
10 years ago

People

(Reporter: chris, Assigned: kinmoz)

Tracking

Trunk
mozilla1.3beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Text copied from my comment in Bug 88049. Please switch Platform/OS:ALL if
you're seeing this elsewhere.

Just trying to hack together some quick editor buttons (similar to that of
blogger and movable type) at hit some strange behavior (that is available in the
current testcase). It seems that when a user highlights all the text with the
mouse selectionEnd == length, however when selecting all text with CMD/CTRL-A
selectionEnd == length + 1. While inserting text at this higher value seems to
work properly, it screws with resetting focus in the following example:

http://placenamehere.com/Mozilla/js_textareas.html

You'll notice that if you select all the text in the textarea via CMD-A and then
hit one of the editor buttons it throws off my calculation for the new
selectionEnd and grabs the first character in the newly inserted tag.

My Build:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030122


While I can easily test that the selection isn't longer the then length in my
script to get it to work, should I have to? Is there a reason for this behavior?
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
OS: MacOS X → All
Priority: -- → P3
Hardware: Macintosh → All
Summary: selectionEnd off by one when user selects text via CMD/CTRL-A → selectionEnd off by one when user selects text via CMD/CTRL-A
Target Milestone: --- → mozilla1.3final
(Assignee)

Comment 1

16 years ago
Created attachment 112463 [details] [diff] [review]
Patch Rev 1

Here's the patch that fixes the problem. We shouldn't be counting the last BR
under the root node as a character. I also fixed 3 warnings related to signed
comparisons.
(Assignee)

Updated

16 years ago
Attachment #112463 - Flags: superreview?(sfraser)
Attachment #112463 - Flags: review?(jkeiser)

Updated

16 years ago
Attachment #112463 - Flags: superreview?(sfraser) → superreview+

Updated

16 years ago
Attachment #112463 - Flags: review?(jkeiser) → review+
(Assignee)

Updated

16 years ago
Flags: blocking1.3b?

Comment 2

16 years ago
Comment on attachment 112463 [details] [diff] [review]
Patch Rev 1

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #112463 - Flags: approval1.3b+

Updated

16 years ago
Flags: blocking1.3b?

Updated

16 years ago
Keywords: nsbeta1+
(Assignee)

Comment 3

16 years ago
Fix checked into TRUNK:

  mozilla/layout/html/forms/src/nsTextControlFrame.cpp  rev 3.114

Fix should appear in 8am trunk daily builds and the Mozilla 1.3 beta.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.3final → mozilla1.3beta
(Reporter)

Comment 4

16 years ago
Confirming Fix on OS X/MachO Nightly:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030201

thx for the fast turnaround

Updated

10 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.