606192 - After drag & drop any link/text/image to contents area, mouse click chrome elements does not work

Status: RESOLVED FIXED

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

Description

[Alice0775 White]

Build Identifier: 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020120347

After drag & drop any text/image to contents area, mouse click chrome elements does not work.

Clicking is necessary twice.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with -P option
2. Open about:home or any web site
3. drag & drop any text/link/image to the contents area
4. try to click Menu, toolbarbutton  and tab.

Actual Results:
 mouse click chrome elements does not work  
 Clicking is necessary twice.

Expected Results:
 mouse click chrome elements should work

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/f68f9d741b29
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre ID:20101019023906
Fails:
http://hg.mozilla.org/mozilla-central/rev/154f493a36dc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre ID:20101019014003
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f68f9d741b29&tochange=154f493a36dc

Comment 1

[Alice0775 White]

This problem does not happen on Linux.
http://hg.mozilla.org/mozilla-central/rev/4788083ce564
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101021 Firefox/4.0b8pre ID:20101021030951

Comment 2

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

So where should I drag something to content area?

Comment 3

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

Ah, doesn't happen on Linux :(

Comment 4

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

But still, do I need to drag something from desktop to content area or from
chrome? Or from a content page to another content page?

Comment 5

[Alice0775 White]

(In reply to comment #2)
> So where should I drag something to content area?
a link in the contents area to its own content area
a link in the content area to desktop
a link in the contents area to bookmarks tool bar
a link in the contents area to tab bar
etc etc etc

Comment 6

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

I pushed a patch to tryserver (244e65776b0c), which might help here.

Comment 7

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

So far I haven't managed to reproduce this on Windows 7.

Comment 8

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

I do see one problem which this
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-244e65776b0c/tryserver-win32/
fixes.
Alice, could you test that build?

Comment 9

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

Attachment: possible patch

This fixes the one problem I saw (active state was kept in a chrome element),
but since I couldn't reproduce this bug, it is hard to say whether this
fixes the reported bug too.

Comment 10

[Alice0775 White]

(In reply to comment #7)
> So far I haven't managed to reproduce this on Windows 7.

[STR1]
1.Open about:home
2.Drag a link "About Mozilla" to white area of contents (Of course nothing happen)
3.Click [+] New Tab Button

[Actual]
Nothing happens

[Exected]
Open New tab 

[STR2]
1.Open about:home
2.Drag a link "About Mozilla" to Desktop
3.Click [+] New Tab Button

[Actual]
Nothing happens

[Exected]
Open New tab 

[STR3]
1.Open https://wiki.mozilla.org/WeeklyUpdates
2.Select text
2.Drag selected text to contents body (Of course nothing happen)
3.Click [+] New Tab Button

[Actual]
Nothing happens

[Exected]
Open New tab 

(In reply to comment #8)
> I do see one problem which this
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-244e65776b0c/tryserver-win32/
> fixes.
> Alice, could you test that build?

*This tryserver build breaks the following test case.
https://bug603550.bugzilla.mozilla.org/attachment.cgi?id=483440

*One thing improved
Drag & drop something to input of contents .

*No thing changed(after following, fails to click chorom element)
Drag & drop something to contents body
Drag & drop something to desktop

http://hg.mozilla.org/try/rev/244e65776b0c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101021 Firefox/4.0b8pre ID:20101021111229

BTW,
This problem happens on Windows XP too.

Comment 11

[Alice0775 White]

My bad.

>*This tryserver build breaks the following test case.
>https://bug603550.bugzilla.mozilla.org/attachment.cgi?id=483440

This testcase broken on last m-c nightly too
http://hg.mozilla.org/mozilla-central/rev/4788083ce564
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101021 Firefox/4.0b8pre ID:20101021042123

Comment 12

[Alice0775 White]

(In reply to comment #11)

I commented, Please see
https://bugzilla.mozilla.org/show_bug.cgi?id=603550#c21

Comment 13

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

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-810712c8674a/
works here.
Alice, could you perhaps try that?

Comment 14

[Alice0775 White]

(In reply to comment #13)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-810712c8674a/
> works here.
> Alice, could you perhaps try that?

The tryserber build works fine!
And I can not reproduce this problem any more on the tryserber build.

Comment 15

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

Attachment: patch

So when we're doing dragging, don't mark any ESM active.
Also, when mousedown tries to set the active content, don't
clear any existing active content. This way the patch doesn't
break <button>'s active state.

The patch is a bit hackish, but :active handling needs some bigger,
post-FF4 clean-ups.

And tests are still missing. Not all dnd can be tested automatically, 
but some can be. I'll write the tests.

Comment 16

[Neil Deakin]

Comment on attachment 485750 [details] [diff] [review]
patch

Could you add some more comments in general to the patch?


>   case NS_DRAGDROP_DROP:
>     {
>+      ClearGlobalActiveContent(this);

I assume it's ok to do this in-between this and the older dragdrop event?

What effect would it have on some old addons?

Comment 17

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

Ah, right. I'll move that to happen after the
older dragdrop.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Smaug asked me very nicely on IRC if this could get dispensation to go into beta7. I told him that:

 - if he wrote really good tests,
 - and if he passed the whole thing through tryserver,
 - then yes.

Comment 19

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

Attachment: +tests

Comment 20

[Jake]

I take it for granted that anybody who encountered this problem installed "Easy DragToGo" otherwise you drag text/link/image for what? Today I review this thread again finding out actually nobody has mentioned this addon. Maybe this why somebody claimed they don't have the problem.

Comment 21

[Alice0775 White]

I never use such addon.

As a default function of firefox:
Drag link/text/imagelink to textarea/desktop.
Drag link/imagelink to bookmarks toolbar/bookmarks sidebar.
Drag link/text/imagelink to body in order to cancel.

This bug affect the above action.

Comment 22

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

Pushed http://hg.mozilla.org/mozilla-central/rev/66b7220a7c35

Comment 23

[Jake]

(In reply to comment #21)
> I never use such addon.
> 
> As a default function of firefox:
> Drag link/text/imagelink to textarea/desktop.
> Drag link/imagelink to bookmarks toolbar/bookmarks sidebar.
> Drag link/text/imagelink to body in order to cancel.
> 
> This bug affect the above action.

I don't know that actually, I only drag link/image to force it open in new tab, drag text to search.