Closed Bug 48857 Opened 24 years ago Closed 23 years ago

:active still set on objects after drag

Categories

(Core :: XUL, defect, P3)

x86
Windows 98
defect

Tracking

()

RESOLVED FIXED
mozilla0.9.1

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(1 file)

Build ID: 2000081308

Steps to Reproduce:
(1) With PT D&D off (in the prefs debug pane), drag the classic Home button 
somewhere and then release the mousebutton.  Note that the image reverts back 
to the normal (non-shady/dark) icon once you release the mousebutton.
(2) Now with PT D&D on, do step 1 (drop the Home button into some dead space).  
Note that this time the image still remains the same shady, dark icon, meaning 
that the button is still in the :active state -- but it shouldn't be, since you 
dropped it.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
assuming this is what it is, resummarizing.
Summary: Widgets need to get back in 'normal' state after being dropped → :active still set on objects after drag
Target Milestone: Future → mozilla1.0
*** Bug 20017 has been marked as a duplicate of this bug. ***
This also happens on regular links that have :active set on them.

If you click and hold a link, you see the active, but then you drag the mouse 
off the link, the link still shows active.  If you then click somewhere else on 
the page, the link just gets repainted with a gray background (as if Mozilla 
was confused as to what to do with it).  Now hovers don't work over that link 
where they did before and the only ways to get out of that state is doing a 
normal click on the link or reloading the page.

BTW, the links I was testing were javascript: links which popped up new windows 
so they didn't leave the page when clicked on.

you can see these at http://www.visi.com/~hoju/indextest.html (experimental css 
page, so it may change in the future).  Use the "List all links on this page" 
or "extended browser info (NS only)" javascript: links.

Jake
"after drag" means "after the mouse has been released", right? Because _during_
the drag, the item that released the mouseclick event _is_ still in :active.

cc'ing hyatt who mentioned this earlier today.
On further investigation, I click and hold a link which puts it in :active 
state.  Then, as I continue holding the mouse down, I drag the mouse off the 
link.  Now I let the mouse button up.  The link continues to display in 
its :active state.

Now, if I click on any part of the background of the page, the link turns gray 
and ignores the :hover.  However, if I click on some text on the page, the gray 
goes away and the link returns to a normal non-grayed and non-:active state.


You might look at one other quirk.  Try the above on the link that looks like 
this (at http://www.visi.com/~hoju/indextest.html ):

extended 
browser info (NS
only) 

Notice that when the link gets into :active state, it looks like this:

extended 
browser info (NS
(NS only) 

Notice that it recopied the "(NS" to the line below AND that it didn't erase it 
on the line above (which continues to display itself in the :hover state).  
Getting it out of :active state causes a reflow to bring the link back to 
normal.

So "extended browser info" + "(NS only)" gets put into :active (white text on 
black background) and " (NS" stays in :hover (orange text on yellow background).

Not sure what summary to come up with for that bug.  Ian, maybe you can submit 
the bug if you can come up with a more concise explanation of what is going on 
here.

Jake
*** Bug 41694 has been marked as a duplicate of this bug. ***
Attached patch patchSplinter Review
Ignore the spacing crap, fix is a one-liner once we stop tracking the 
draggesture to reset things back to the way they were.  cc'ing Chris for review.
Assignee: pinkerton → blakeross
Status: ASSIGNED → NEW
(where "Ignore the spacing crap" == "it won't exist in the patch I checkin")
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.1
We actually don't have to reset :hover for the content, just :active.
r=saari
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: