Closed Bug 421486 Opened 13 years ago Closed 13 years ago
automatic unwanted scrolling for no reason, due to scroll arrow/bar interaction
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030700 Minefield/3.0b5pre ID:2008030700 minotaur 11 from the mz forum made these STR: 1. New profile, start firefox. 2. Visit a long page, eg: https://bugzilla.mozilla.org/show_bug.cgi?id=391598 3. You are at the top of the page. Left click and hold the down arrow scroll button. 4. Whilst keeping the left mouse button pressed, move the mouse up into the scrollbar area. 5. Whilst keeping the left mouse button pressed, move the mouse into the browser window. 6. Release the left mouse button. Expected: - Scrolling of page stops Actual: - Scrolling down continues, even if you use your mouse-wheel or the PgUp button. The only way to stop the scrolling is to left-click in the scrollbar area, but not on the scrollbar itself.
This is also a regression as a Fx 184.108.40.206pre build does not show this behaviour. I'll request blocking so it can be mark wanted ;)
It is actually slightly worse than described. Not only does the autoscrolling continue even after switching tabs, once it gets down to the bottom of the page you can not scroll backup using the mousewheel without the page autoscolling to the bottom again. The only way to stop being permanently stuck at the bottom of the page is to click in the scrollbar. At work now but will try to find a regression range later today.
Works: 20080226_0310_firefox-3.0b4pre.en-US.win32 Broken: 20080226_0557_firefox-3.0b4pre.en-US.win32 Checkins to module PhoenixTinderbox between 2008-02-26 03:10 and 2008-02-26 05:57 : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-26+03%3A10&maxdate=2008-02-26+05%3A57&cvsroot=%2Fcvsroot Due to bug 389931 or bug 411054. I'll guess the former since that's caused so many regressions and this doesn't seem like a DOM bug.
Note: Step 5 is not required.
Confirmed under Linux as well.
OS: Windows XP → All
Hardware: PC → All
+'ing with P2. This is just bad.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Backing out bug 389931 locally: bug still occurs Backing out bug 411054 locally: bug does not occur
Mats, are you familiar enough with event handling code? The patch backs out the (functional) change bug 411054 made to doPreHandleEvent. FindFirstNonNativeAnonymousAncestor may return object which is still inside native anonymous subtree (in case of nested native anonymous objects), nsIContent::FindFirstNonNativeAnonymous returns an object which truly is outside native anonymous.
Comment on attachment 308636 [details] [diff] [review] proposed patch (In reply to comment #8) > Mats, are you familiar enough with event handling code? Not to the degree that I can review this patch. Ask Boris or Jonas?
Comment on attachment 308636 [details] [diff] [review] proposed patch OK. Jonas, this is backing out the change I made to doPreHandleEvent. Just using different name for the function.
So this will make us target non-anonymous nodes even if they are descendants of anonymous nodes. That would seem to make sense. We will still retarget once we go outside of the anonymous ancestor, right?
Well, I wouldn't call this retargeting, but stopping propagation in case mouseover/out happens somewhere in native anonymous subtree. This backout prevents stopping progation too early in native anonymous subtree.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.