[EV]Dragging away from and back to scroll button doesn't resume scrolling

RESOLVED INACTIVE

Status

()

Core
Event Handling
--
trivial
RESOLVED INACTIVE
18 years ago
a day ago

People

(Reporter: Keith Lea, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m16) Gecko/20000603
BuildID:    200060315

Reproducible: Always
Steps to Reproduce:
1. click and hold the down- or up-arrow on the scrollbar of any document
2. drag the mouse off of the arrow, while still holding down the button
3. drag the mouse back on to the arrow

Actual Results:  The document does not resume scrolling

Expected Results:  The document should continue scrolling..

Comment 1

18 years ago
updating component and reassigning to default owner.  Confirming with 060508
build under Mac and WinNT
Assignee: asa → trudelle
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
OS: Windows 95 → All
QA Contact: jelwell → jrgm
Hardware: PC → All

Comment 2

18 years ago
I believe joki owns the general problem, this is probably a dup. reassigning, 
cc saari
Assignee: trudelle → joki
Component: XP Toolkit/Widgets → Event Handling

Comment 3

18 years ago
Reassigning to evaughan per our conversation.
Assignee: joki → evaughan

Comment 4

18 years ago
Note: native behaviour on mac and win32 is to stop on mouseout, and resume
on mouseover. However, gtk and motif behaviour on linux is to continue to 
scroll as long as mousedown, no matter where the mouse is moved.

Comment 5

18 years ago
targeting
Status: NEW → ASSIGNED
Target Milestone: --- → M20

Comment 6

18 years ago
*** Bug 46283 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
Nom. nsbeta3 -- this is a common UI gesture to move through documents. It's 
expected behaviour. 
Keywords: nsbeta3

Comment 8

18 years ago
nsbeta3-
Whiteboard: [nsbeta3-]
Target Milestone: M20 → Future

Comment 9

18 years ago
*** Bug 44522 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
*** Bug 57281 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
[Shortening summary.]
Summary: dragging the mouse off of the arrows on page scrollbars does not allow one to drag back on to continue scrolling → Dragging away from and back to scroll button doesn't resume scrolling

Comment 12

18 years ago
I've been looking at this for awhile tonight.  Reassigning to me, but judging 
from what I learned, I think this is going to end up on saari's or joki's plate 
(details coming tomorrow).
Assignee: evaughan → blakeross
Status: ASSIGNED → NEW
Keywords: nsbeta3
Whiteboard: [nsbeta3-]

Comment 13

18 years ago
Okay, so, I set up a simple test in nsScrollbarButtonFrame.cpp by which I'd 
break into the debugger upon moving the cursor back over the scrollbarbutton 
after having pressed it and moved off of it (with the left mousebutton still 
down).

Upon moving over the scrollbarbutton the second time, aEvent->message was 331, 
which, according to nsGUIEvent.h, is NS_MOUSE_ENTER_SYNTH 
(http://lxr.mozilla.org/seamonkey/source/widget/public/nsGUIEvent.h#398).  So 
nsScrollbarButtonFrame does nothing with the event and passes it on to 
nsButtonBoxFrame to handle, which also does nothing and then passes it on to 
nsFrame::HandleEvent to handle.  An NS_MOUSE_LEFT_BUTTON_DOWN event is 
(logically) the only event there which calls ::HandlePress (which would 
continue scrolling), but there's no condition for NS_MOUSE_ENTER_SYNTH, so we 
hit the default case and die.

I don't understand why we're getting an NS_MOUSE_ENTER_SYNTH instead of an 
NS_MOUSE_LEFT_BUTTON_DOWN when we re-enter the scrollbarbutton.  I traced it 
all the way out to nsWindow::ProcessMessage, where the OS is handing us an 
WM_MOUSEMOVE.

Chris, thoughts?
Status: NEW → ASSIGNED

Comment 14

18 years ago
conceptually, we have a _REENTER event, but why wouldn't you get both an _ENTER 
and some sort of click move event?

Updated

17 years ago
Priority: P3 → P1
Target Milestone: Future → mozilla0.9.1

Comment 15

17 years ago
This has regressed a bit further; now the scrollbar arrow doesn't depress when 
the cursor reenters.  I haven't investigated yet, but I'd guess this 
(regression, not the original problem) is somehow related to bug 78343.

Comment 16

17 years ago
I filed that as bug 80462, but I don't think it should affect this bug. Other
widgets are reacting to the mouse just fine (they do whatever they're supposed
to do when the mouse button is released); they just aren't displaying mousedown
appearance when the cursor returns.

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

17 years ago
Priority: P1 → P3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla1.0

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.1

Comment 17

17 years ago
-> rods
Assignee: blaker → rods
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1 → ---

Comment 18

17 years ago
This would be an Eric Vaughan bug.
Status: NEW → ASSIGNED
Summary: Dragging away from and back to scroll button doesn't resume scrolling → [EV]Dragging away from and back to scroll button doesn't resume scrolling
Target Milestone: --- → Future

Updated

17 years ago
Priority: P3 → --
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → events

Comment 19

a day ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: a day ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.