494026 - Drag&Drop a tab onto the new tabbutton in the toolbar doesn't duplicate tab

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090520 Shiretoko/3.5b5pre ID:20090520035357

Having the new tab button on the toolbar visible and drag&drop a tab on it, no new tab will be opened. This is a regression against Firefox 3.

Steps:
1. Open customize toolbars and drag new tab button to the navigation bar
2. Drag a tab and try to drop it onto this icon

Step 2 will fail and now new tab will be created.

Comment 1

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

Will be fixed by bug 493978

Comment 2

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/releases/mozilla-1.9.1/rev/bd95115df4f2

Comment 3

[Aakash Desai [:aakashd]]

I'm still not seeing a new tab created after performing step 2

Build Id:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre ID:20090522030802


Henrik are you still seeing this or am I doing this incorrectly?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

You are doing it right. This bug is not fixed on trunk and 1.9.1. Removing dependency since it has not been fixed by bug 493978. Putting on blocking1.9.1? list to get feedback from drivers.

=> Reopen

Comment 5

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

Doesn't block, would take fix now or on security and stability!

Comment 6

[Asaf Romano (gone)]

Oh, it was applied on the newWindow button for some reason :(

Comment 7

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

a191=beltzner for the one line fix required here ...

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Is this the one-liner we need? Seems like we should take this for RC2 if we do one.

Comment 9

[Asaf Romano (gone)]

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

yes, thanks.

Comment 10

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

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

a191=beltzner

Comment 11

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

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1726d2e0d383 kinda by accident, but w/e

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 ID:20090624012136

Comment 13

[Maxwell]

I am running Firefox 3.5 RC3 on Windows, and it seems to be fixed here. about:buildconfig reports "Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a625a31a0ad1"

Comment 14

[Jim Jeffery not reading bug-mail 1/2/11]

Is only for 3.5 ?  As it does not seem to work with the latest hourly trunk build.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090629 Minefield/3.6a1pre Firefox/3.0.11 ID:20090629023759

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, it needs to be checked into trunk.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

http://hg.mozilla.org/mozilla-central/rev/5b8ff3412c80 obsoleted that patch on the trunk. I'm not sure offhand why this is happening on the trunk.

Comment 17

[Frank Yan (:fryn)]

(In reply to comment #1)
> Will be fixed by bug 493978

Since bug 493978 was fixed and this patch was checked in, this now works in both Firefox 3.6 and the trunk.

Should be marked FIXED or WORKSFORME.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dao, is there any work planned to setup a list of d&d browser-chrome tests for tabs? We could add tests to Litmus but seeing those tests in the test suite would be much better.

Comment 19

[Dão Gottwald [:dao]]

No, there's no such plan.

This is WFM as it's not clear what fixed this. See previous comments.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #19)
> No, there's no such plan.

I've filed bug 551921 as a starting point.

Comment 21

[u279076]

Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12800