851103 - Drag and dropped elements like links remain :active

Status: RESOLVED DUPLICATE of bug 379272

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jim Mathies [:jimm]]

Odd rendering bug I ran across today in bugzilla.

str:

1) open up any page with standard text links (bugzilla bugs work)
2) click down on a text link and drag the link off of itself a bit
3) release the mouse

the original link text will be rendered as normal text, rather than as a link.

4) click anywhere on the page to set focus

link text returns.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is not working for me with a simple test page:

  data:text/html,<a href="http://web.mit.edu/something">aaa

I do see it with Bugzilla, but that might be a matter of the :active styling in the Bugzilla stylesheets...

Comment 2

[Jim Mathies [:jimm]]

Ah, maybe this is a bugzilla 4.2 regression. I've tried a couple different sites and can't reproduce either.

Comment 3

[Matthew N. [:MattN]]

The cause is:

    a:active {
        color: #000;
    }

from skins/standard/global.css

This is actually a Bugzilla issue (not BMO-specific).

Comment 4

[mjh563]

It sounds like a Firefox bug then. A link shouldn't stay 'active' after it's been dragged and released, should it?

It works as expected in Firefox nightlies before 2010-10-29 (the link changes back to the 'normal' styling when the mouse button is released).

Last good nightly: 2010-10-28
First bad nightly: 2010-10-29

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fe4898e97431&tochange=799a83ba5f86

There's also a different bug, relating to the styling of the link *while it's being dragged* (before releasing the mouse button): 

Sometimes both the original and the dragged copy will be blue.
Sometimes both the original and the dragged copy will be black.
Sometimes the original will be black but the dragged copy will be blue.

Comment 5

[mjh563]

Attachment: testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

The obvious thing in that range is bug 606192.

Comment 7

[Roman]

As pointed out by mjh563, could bug 865409 be caused by the same thing?

Comment 8

[mjh563]

Attachment: tentative patch

This one-line patch fixes the issue on my Linux build without breaking anything obvious. I don't really understand the code enough to know why though.

The line removed by the patch was added in the fix for bug 606192.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Review coming by the end of this week.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 758884 [details] [diff] [review]
tentative patch

I don't think we want this.
Could you try SetActiveManager(nullptr, nullptr)

Comment 11

[mjh563]

Attachment: tentative patch 2

Smaug, thanks for the review.

Your suggestion works to clear the active content, except that it clears it when dragging starts, not when it ends. I think it should be cleared at the end of the drag instead.

So maybe something like this patch would work? What do you think?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 778999 [details] [diff] [review]
tentative patch 2

Ah, this might work.
Could you write some tests. I know testing dnd can be tricky, but we really
tests for this.

Comment 13

[mjh563]

I tried creating a mochitest to drag and drop a link, but I couldn't get it to work properly. The mousedown and mousemove started the drag as expected, but the mouseup event never triggered the drop, so the test ended with the drag still in progress.

I'll have another attempt and attach the results, and hopefully you'll be able to point out where I'm going wrong.

Comment 14

[mjh563]

Unfortunately I'm not making any progress with writing tests for this. If someone else wants to take it over, please do.