Closed Bug 290553 Opened 20 years ago Closed 20 years ago

gradually dragging selection upwards makes it jump to the top

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugs.caleb, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

minimal testcase
1.86 KB, text/html
Details
fix
1.91 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
brendan
: approval1.8b2+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050415 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050415 Firefox/1.0+ 1. Open the given URL 2. Scroll to the bottom 3. Start your selection from the end of the last paragraph ("Denmark and his native Morocco. ") 4. Keep your left mouse button pressed and move your mouse to the top of the visible page. (slow down when you get your mouse near the tab bar, and then gently tip it over while having the mouse pressed). The page should scroll up gently with the selection, but instead it quickly bounces to the top of the page. Reproducible: Always
Attached file minimal testcase —
<body>&nbsp;000<br>&nbsp;001<br> ... &nbsp;099<br></body></html>
confirming Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050415 Sounds similar, but is completely different: Bug 256400 Unexpected jumps when selecting text
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
I get the actual results (bouncing quickly at the top of document) with the testcase (attachment 180871 [details]) when trying with Mozilla 1.8b2 build 2005041506 under XP Pro SP2. I tested the same testcase but with <p>001...099</p> instead of one hundred &nbsp;001<br> and I also got the actual results. IMO, this must be a recent regression. Normally it was preferable to resolve this bug as a duplicate of bug 290374. "newer bugs should be made DUPLICATES of older bugs"
*** Bug 290374 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050410 testcase is working in BuildID 2005041005, failing in BuildID 2005041504
Keywords: regression
Also seeing this bug. The bug name is technically true but a bit misleading, since what I had been doing is drag-selecting downwards, then making a slight correction (deselecting some of the selection by dragging upwards), which triggers the bug. This is _quite_ the regression (especially if you add it to the numerous existing BiDi text selection bugs...)
There seems to be other visual signs of this bug. - drag the vertical scrollbar thumb upward or downward: the cursor is deflected by 15-20 pixels toward the top. The cursor "jumps" toward the top. Those who are familiar with DHTML drag-N-drop effect will recognize this sort of miscalculation of the box frame to be dragged - drag a bookmark in manage bookmark window. The line indicating the new position of the bookmark is offset by -50 pixels or so when comparing with the mouse cursor. Mozilla 1.8b2 build 2005041506 under XP Pro SP2 here.
There've been lots of quirks with selection/scrolling recently. I've found another interesting bug (if it's not related to this one I can open a new one) It's a pain to reproduce but here goes: 1. Open http://www.apple.com/macosx/ 2. On the right side of the screen there's a "table" with the header "Purchase Mac OS X Tiger" 3. Put your mouse over the blank space to the left of that table (there's about 1 inch of space between the right side tables and the left side that contains text) 4. Now left click in that empty area and pull your mouse down very gently. You will notice that the slightest movement scrolls the page VERY quickly to the bottom.
(In reply to comment #9) > There've been lots of quirks with selection/scrolling recently. > > I've found another interesting bug (if it's not related to this one I can open a > new one) You´ve seen enough of testcases in your bugs, perhaps you can try to make one yourself? Mail me if you have questions how to proceed. > It's a pain to reproduce but here goes: It´s easy to reproduce: > 1. Open http://www.apple.com/macosx/ > 2. On the right side of the screen there's a "table" with the header "Purchase Mac OS X Tiger" Above that table is a black link bar: New features Overview ... Upgrade Hover over that bar and note how the Buttons change color when getting focus. Hover down until focus is lost, and then > 4. Now left click in that empty area and pull your mouse down very gently. > You will notice that the slightest movement scrolls the page VERY quickly to the > bottom. I had trouble editing that comment, when it got higher than the box, I had to cut it out, edit it externally and then paste back. Seems to be the same bug ;-)
Sorry Hermann, but I don't always have the time to make testcases. As you've seen in my previous bugs I _have_ made a few, but sometimes I try to report the bug as soon as possible. (And I thank you for your testcases :)) Your way of reproducing also works :) (And yes, it's not painful.. I wrote that painful bit and forgot to edit it out)
Testcase is reproducible on Mac OS X as well.
==> roc
Assignee: selection → roc
Flags: blocking1.8b2?
OS: Windows XP → All
Flags: blocking1.8b2? → blocking1.8b2+
Attached patch fix — — Splinter Review
The canvas frame just needs to update its event coordinates when passing the event to its child, if it has a view.
Attachment #180997 - Flags: superreview?(bzbarsky)
Attachment #180997 - Flags: review?(bzbarsky)
Comment on attachment 180997 [details] [diff] [review] fix >Index: layout/generic/nsHTMLFrame.cpp >+ GetOffsetFromView(pt1, &eventView); >+ firstChild->GetOffsetFromView(pt2, &newEventView); >+ nsPoint offset = eventView->GetOffsetTo(newEventView); Want to flip that to: nsPoint offset = -(newEventView->GetOffsetTo(eventView)); ? This should be faster, since the newEventView belongs to a child... r+sr=bzbarsky with that.
Attachment #180997 - Flags: superreview?(bzbarsky)
Attachment #180997 - Flags: superreview+
Attachment #180997 - Flags: review?(bzbarsky)
Attachment #180997 - Flags: review+
Comment on attachment 180997 [details] [diff] [review] fix Fixing another mouse event handling regression ... hopefully the last one!
Attachment #180997 - Flags: approval1.8b2?
Comment on attachment 180997 [details] [diff] [review] fix a=brendan for 1.8b2. /be
Attachment #180997 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: