330013 - Dragging a link to the tab bar opens in the currently focused tab, not a new tab

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Simon Montagu :smontagu]

Drag a link to the tab bar, to the right of all currently open tabs.

Expected result: the link is loaded into a newly created tab.
Actual result: the target loads in the currently focused tab.

This is a regression from bug 324335.

Comment 1

[Martijn Wargers (dead)]

Well, I can't reproduce this, I get the expected result. Maybe this is a Linux only problem?

Comment 2

[Simon Montagu :smontagu]

In my build aEvent.originalTarget.localName is always tabbrowser, whether I drop on the tab bar or an existing tab. 

document.getBindingParent(aEvent.originalTarget) is always null.

Comment 3

[Martijn Wargers (dead)]

(In reply to comment #2)
> document.getBindingParent(aEvent.originalTarget) is always null.
So you get a js error in the console then?

Weird that for you aEvent.originalTarget.localName is always tabbrowser.
Do you use some special theme or something?

Comment 4

[Simon Montagu :smontagu]

(In reply to comment #3)

> So you get a js error in the console then?

No, I don't, which is something I don't understand.
 
> Weird that for you aEvent.originalTarget.localName is always tabbrowser.
> Do you use some special theme or something?

No, and I get the same result in a clean profile. 

Comment 5

[Simon Montagu :smontagu]

OK, I figured out the console issue: if I set javascript.options.showInConsole to true, I get Error: document.getBindingParent(aEvent.originalTarget) has no properties
Source File: chrome://global/content/bindings/tabbrowser.xml
Line: 1652

Comment 6

[Martijn Wargers (dead)]

Ah yes, you should have turned that on.
So if you back out the patch for bug 324335, you get bug 324335 back, right?
I really have no idea why you get this problem, so I can't really help :(

Comment 7

[Simon Montagu :smontagu]

It seems likely that the underlying problem here (i.e. the target always being tabbrowser) was caused by bug 308936, but it will take some time to test that assumption since the patch doesn't cleanly reverse-apply. It doesn't happen on my 1.8 branch build from January 31.

Comment 8

[Simon Montagu :smontagu]

> It seems likely that the underlying problem here (i.e. the target always being
> tabbrowser) was caused by bug 308936.

That would be bug 308396.

Comment 9

[Simon Montagu :smontagu]

Apparently not bug 308396 either. In a build pulled by date from 2006-01-19 and then attachment 209152 [details] [diff] [review] applied I can't reproduce the bug.

Comment 10

[Simon Montagu :smontagu]

I've located a regression window between 2006-03-06 and 2006-03-08, which seems to point at bug 234455. I thought the patch from bug 330190 might fix it, but it seems it doesn't :(

Comment 11

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

I see this in Linux only, not in Windows. Drag-and-Drop events are handled somehow in a bit different way. Hmm, my windows build was a cairo, Linux build old-style
gtk2 - could that cause any difference?

Comment 12

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

The bug is there also with cairo-gtk2.
Haven't yet found the reason why the event is dispatched to wrong target.
(That is the problem as far as I understand, event dispathing seems to work properly.)

Comment 13

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

Attachment: proposed patch

Comment 14

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

So the problem is that dnd code in nsWindow (gtk/gtk2) reuses nsEvents.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 214831 [details] [diff] [review]
proposed patch

r+sr=bzbarsky

Comment 16

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

Checking in nsPresShell.cpp;
/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.900; previous revision: 3.899
done