48857 - :active still set on objects after drag

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Blake Ross]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

assuming this is what it is, resummarizing.

Comment 2

[Mike Pinkerton (not reading bugmail)]

*** Bug 20017 has been marked as a duplicate of this bug. ***

Comment 3

[Jacob Kjome]

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

Comment 4

[Hixie (not reading bugmail)]

"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.

Comment 5

[Jacob Kjome]

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

Comment 6

[Gervase Markham [:gerv]]

*** Bug 41694 has been marked as a duplicate of this bug. ***

Comment 7

[Blake Ross]

Attachment: patch

Comment 8

[Blake Ross]

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.

Comment 9

[Blake Ross]

(where "Ignore the spacing crap" == "it won't exist in the patch I checkin")

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 11

[Blake Ross]

We actually don't have to reset :hover for the content, just :active.

Comment 12

[saari (gone)]

r=saari

Comment 13

[Blake Ross]

Fixed.