Closed Bug 624127 Opened 15 years ago Closed 14 years ago

mouse movement changes selected text even when no key or mouse key is pressed

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b12
Tracking Status
blocking2.0 --- .x+

People

(Reporter: kdevel, Assigned: enndeakin)

References

Details

(Keywords: regression)

Attachments

(2 files, 3 obsolete files)

User-Agent: Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20100101 Firefox/4.0b9pre Mouse movements without keys pressed modify the current text selection as if the left mouse button is still pressed. Reproducible: Always Steps to Reproduce: 1. clear cookies, load www.youtube.com -> box (light blue background) with "Welcome to YouTube! Suggested Location Filte..." appears 2. Place mouse cursor in front of "W" in "Welcome". 3. Click and hold left mouse button until step 5 4. Move (mark) downwards until mouse is in the advertisement image -> text in box is selected 5. release left mouse button. 6. slowly move mouse up Actual Results: Selection shrinks as if left mouse button is still pressed. Expected Results: Keep selection after releasing left mouse button.
Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/bf0fdec8f43b Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090913 Minefield/3.7a1pre ID:20090913032541 Fails: http://hg.mozilla.org/mozilla-central/rev/912c6ae3b70c Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090914 Minefield/3.7a1pre ID:20090914031022 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf0fdec8f43b&tochange=912c6ae3b70c In local build, build from eda2433181c9 : Fails build from 8afb65205203 : works Regressed by: eda2433181c9 Neil Deakin — Bug 503943, add mouse capturing api to elements, remove capturing from views, r=roc,sr=smaug
Blocks: 503943
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Component: General → Event Handling
Product: Firefox → Core
QA Contact: general → events
Version: unspecified → Trunk
blocking2.0: --- → ?
Blocking, but .x. I don't think we absolutely have to fix this for 2.0. Over to Neil as this appears to be a regression from his changes.
Assignee: nobody → enndeakin
blocking2.0: ? → .x
Need a testcase, or at least some steps to reproduce that aren't dependent on what youtube website looks like. (There is no text 'Welcome to YouTube!...' when I view it)
Keywords: testcase-wanted
Attached file testcase (obsolete) —
STR: 1. click and hold before the "N" in the first line 2. drag into the iframe 3. release button 4. move to second line
Attached file testcase
Attachment #507090 - Attachment is obsolete: true
This is caused because SetMouseDownState(PR_TRUE) is called on the parent presshell when the mouse is pressed, and on SetMouseDownState(PR_FALSE) the child frame's presshell when the mouse is released. So SetMouseDownState(PR_FALSE) will need to be retargeted to the right presshell.
Attached file possible patch (obsolete) —
This demonstrates a fix, but it probably isn't the right place to clear the mousedown state.
Attached patch better patch (obsolete) — Splinter Review
Attachment #507140 - Attachment is obsolete: true
Attachment #508459 - Flags: review?(Olli.Pettay)
Attachment #508459 - Flags: review?(Olli.Pettay) → review+
Attachment #508459 - Flags: approval2.0?
frameSelection->SetMouseDownState(PR_FALSE); frameSelection->StopAutoScrollTimer(); } + if (captureContent) { + nsIDocument* doc = captureContent->GetCurrentDoc(); + if (doc) { + nsIPresShell* capturingShell = doc->GetShell(); + if (capturingShell && capturingShell != PresContext()->GetPresShell()) { + nsCOMPtr<nsFrameSelection> frameSelection = capturingShell->FrameSelection(); + frameSelection->SetMouseDownState(PR_FALSE); + frameSelection->StopAutoScrollTimer(); Can we restructure things a little bit so we only have one call to SetMouseDownState and StopAutoScrollTimer?
Attachment #508459 - Flags: approval2.0? → approval2.0+
Attachment #508459 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: