445416 - Scrolling keeps going on when mousedown on the scrollbarbutton and mouseup somewhere in scrollbar

Status: RESOLVED FIXED

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

Description

[Martijn Wargers (dead)]

To reproduce:
- Mousedown on the scrollbar buttton, keep the mouse button pressed
- Then move the mouse somewhere else in the scrollbar

Actual result:
Notice that the scrollbar keeps moving, it doesn't even matter that you release the mouse button.

Actual result:
The scrollbar should stop scrolling.

This regressed between 2008-06-22 and 2008-06-23.
I have no idea how to get a bonsai link, lately, maybe a fixed bugs list between those dates is useful?
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-06-21&chfieldto=2008-06-23&chfield=resolution&chfieldvalue=FIXED&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Comment 1

[Ria Klaassen (not reading all bugmail)]

I have some more builds and I see a regression between 2008-06-22 22 and 2008-06-23 04: http://hg.mozilla.org/index.cgi/mozilla-central/shortlog/a78c4eeaf51c Olli Pettay - Bug 438241, and also Michael Ventnor with 3 checkins all around the same time within this range. 
Especially the different local times are making it difficult and possibly not error-free.. 

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

ah, probably me :(

Comment 3

[Mats Palmgren (inactive)]

Regression from bug 438241 confirmed by local backout.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

And this is so for me. If I finally could get event propagation work
properly when event is dispatched to native anonymous content...

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

I'll think this still some more, but this should do it. The event propagation
was stopped too early inside native anonymous subtree. So either
stop propagation when event is being handled in a native anon content (root
for the native anon subtree) or if event is dispatched to non-native anon content
but its related target is somewhere in its native anonymous subtree.
Cases when both target and related target are in native anon subtree (but not
necessarily in the same one) make this even more complicated :(

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: simpler

relatedTarget->FindFirstNonNativeAnonymous() ==
target->FindFirstNonNativeAnonymous()
isn't needed anymore, but I want to add some DEBUG_smaug code.

I need to find some reasonable way to test this all automatically...
I tested this bug and other relevant bugs, no regressions.
The printf doesn't show anything bad.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Wed Aug 27 14:11:12 2008 +0300 (at Wed Aug 27 14:11:12 2008 +0300)
changeset 18444	c9bc394e507a

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 329846 [details] [diff] [review]
simpler

not approved for 1.9.0.4, doesn't meet the new stricter criteria. Users will get this in 3.1