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

Status: RESOLVED DUPLICATE of bug 29405

(Core :: XUL, defect, P3)

Description

[Jesse Ruderman]

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

[John Morrison]

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

[Peter Trudelle]

reassigning to evaughan for testing in his latest bits.

Comment 3

[Eric Vaughan]

Looks like you territory

Comment 4

[Nisheeth Ranjan]

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.

Comment 5

[WD]

Verified Win98 2000092808

Comment 6

[Jesse Ruderman]

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.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 8

[Blake Ross]

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

[Daniel Wang]

*** This bug has been marked as a duplicate of 29405 ***