Toolbar buttons stay depressed after click-drag, alt-tab

RESOLVED DUPLICATE of bug 29405

Status

()

Core
XUL
P3
minor
RESOLVED DUPLICATE of bug 29405
18 years ago
15 years ago

People

(Reporter: Jesse Ruderman, Assigned: joki (gone))

Tracking

Trunk
Future
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Steps to reproduce:
1. Over a selected toolbar button (back, forward, etc.), push the left mouse 
button down.
2. Move the mouse outside of the button (drag).
3. While still holding the mouse button down, alt-tab to another app, then alt-
tab back.

Result: toolbar button is still "depressed" (a pixel or a few lower and to the 
right)

Comment 1

18 years ago
I can't duplicate this for the Back, Forward buttons on the left side, but I
can see it if I click-hold the Search <titledbutton> on the right, then drag
off the button, and then ALT-TAB -- yep, the Search button stays depressed
(i.e., in its :active style). [Note: there is a bug for <button> and :active
in the trunk builds that prevents one from seeing the Back,Forward buttons
depress at all].

At any rate, this is related to bug #30384 "Dragging out of toolbar button 
while clicking leaves button depressed".

Comment 2

18 years ago
reassigning to evaughan for testing in his latest bits.
Assignee: trudelle → evaughan

Comment 3

18 years ago
Looks like you territory
Assignee: evaughan → joki

Comment 4

18 years ago
Even the search button is getting restored properly when you move the mouse 
outside the button while holding down the mouse button.  I'm using 
today's win32 build.  Marking worksforme.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 5

17 years ago
Verified Win98 2000092808
Status: RESOLVED → VERIFIED
(Reporter)

Updated

17 years ago
Severity: normal → minor
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 6

17 years ago
Still broken.

1. Mousedown on reload
2. Alt-tab
3. Mouseup
4. Switch back
5. Move mouse cursor back over reload

Result: reload in "depressed" state when the cursor is over it
Expected: reload in "hover" state when the cursor is over it

Clicking in an empty area of the chrome (taskbar, navigation toolbar, etc) 
makes it start acting correctly again, but clicking in the content area doesn't.
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
(Reporter)

Updated

17 years ago
Blocks: 67277

Comment 8

17 years ago
Houston, we have a problem...it seems that Windows doesn't notify us of an 
WM_LBUTTONUP if you mouseup after alt+tabbing out of the document.  We could 
fix this in a probably safe but very, very sucky way by resetting the 
hover/active content states when the window is activated (for a reason still 
unknown to me, doing so on deactivation doesn't work, even though it gets 
hit).  Dan, Chris, what do you guys think?

Comment 9

15 years ago

*** This bug has been marked as a duplicate of 29405 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.