491530 - Dragging a tab onto homepage button doesn't set it as homepage

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[fake.fakeness]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

In the old firefox it was possible to drag a tab onto the homepage button and you would be prompted to set your homepage to this tab. When I drag a tab onto the homepage button now nothing happens.

Thanks

Reproducible: Always

Steps to Reproduce:
1. Drag tab onto homepage button
Actual Results:  
Absolutly nothing

Expected Results:  
Prompt to set this tab as homepage

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed on Windows XP. Long range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8bfac66fe41a&tochange=262d44d6e425
Possibly bug 475066 ?

Comment 2

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

Yes, I'm pretty sure that this is due to the tab-dragging work. Not sure I'd block Fiefox 3.5 on this, to be honest.

As an immediate workaround, you can still drag the favicon or URL from the location bar and it'll work.

Mano: I'm pretty sure that at one point I told you this would be a "nice to have" and is along the lines of bug 469176 comment 16?

Comment 3

[Luke Iliffe (Harlequin99)]

This sounds the same as bug 465910 that has blocking 3.5 status. By the same logic should this bug not have the same blocking status?

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> This sounds the same as bug 465910 that has blocking 3.5 status.

In that case this bug needs to be marked as duplicate of bug bug 465910, and bug 465910 needs to be reopened.

Comment 5

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

This is also not working on today's trunk: 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090506 Minefield/3.6a1pre Firefox/3.0.7 ID:20090506045618

Seeing this in Console2:
Error: transferData.first is null
Source file: chrome://global/content/nsDragAndDrop.js
Line: 458

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)
> (In reply to comment #3)
> > This sounds the same as bug 465910 that has blocking 3.5 status.
> 
> In that case this bug needs to be marked as duplicate of bug bug 465910, and
> bug 465910 needs to be reopened.

This is a fixed bug and regressed again by another bug.

Comment 7

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

Correct. Same happens when you drag a tab onto the new tabs toolbar button. No new tab will be opened. It's a new regression.

Comment 8

[Dão Gottwald [:dao]]

I don't see why you're moving this to Core.

Comment 9

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

Sorry, that wasn't intended.

Comment 10

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

I don't think this has anything to do with bug 465910, fwiw, I think it's more related to how we no longer pass the URL of a tab to a drop-target when the tab is dragged, which is an intentional change.

As mentioned in comment 2, if you drag the URL from the location bar it will still work. I think this is a similar issue to bug 469176, which is that tabs are no longer proxies for the URLs. Not sure if it's a straight dupe, need Mano's input.

Comment 11

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

Mano: pingpingpingpingping?

Comment 12

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

Don't think it blocks, but if we can get it for RC we should.

Comment 13

[Asaf Romano (gone)]

Fixed by bug 487263.

Comment 14

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

Verified fixed on trunk with builds on all platforms.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre ID:20090520033508

Comment 15

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

As long as the patch on bug 487263 doesn't get backed-out, this is also verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre ID:20090521135222