467376 - Cannot drag and drop a tab into an input or page anymore

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Martijn Wargers (dead)]

I used to be able to drag and drop tabs into text inputs or textarea's and the url of the current page would be there.
Also, when you would drag and drop a tab into the page, the page where it is dragged into would load the url of that tab. That is not possible, either.

Comment 1

[Nochum Sossonko [:Natch]]

I'd imagine the second case is intentional, as now the function assigned is the detach. The first one, IMHO, is also somewhat debatable, I guess the question is, which do you prefer, detach or page load and url insertion? Also, like Marco mentioned in some other bug (can't remember atm) this is due to not offering the "url" flavor in the drag operation.

Comment 2

[Martijn Wargers (dead)]

I don't ever detach a page (I don't even see the need for that, personally).

Comment 3

[Steve McMillen]

If the target is an existing web page, then the drag operation should load the tab into the target page and remove the tab from the previous window (e.g. a move but to replace an existing tab).  This is the concept as what happens if you drag the tag into a blank region of the tab bar in another window - the original tab is moved to the new tab bar.  Only, in this case, you are moving it into an existing tab.

I could live with the new behavior but personally I think its more logical to consider the action of dragging into another window a move to stay consistent.

If the drag is out of any other browser window, then of course, a new window is created and the existing tab is removed from previous tab bar as happens now (nice feature!)

btw: Separtate but related bug: You cannot drag and drop the icon next to the Location bar to create a link in another app.  Now it drops the entire URL.  Used to be, if the drop was in a formatted text region, a hyperlink was created - very nice feature.  I think it *really* needs to come back because is a huge time saver for me.

Incidentally, what happened to voting?  Can't seem to vote any more for a bug.  If I could, I'd vote for a resolution on this as described above.  I guess the trouble with voting is you never know what someone is voting for:)

Comment 4

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

I think this should be fixed by the patch in bug 465184 (onemen.one, can you confirm?)

Comment 5

[Steve McMillen]

This is great.  Thanks.  Sorry for being a bit slow but how do I apply the patch?  I poked around the Minefield package directory but could not see an obvious starting point for executing the 'patch' command. Thanks in advance, Steve

Comment 6

[Nochum Sossonko [:Natch]]

(In reply to comment #5)
You'd have to download the source, apply the patch and build it yourself. Alternatively you may be able to do this with a jar editor, in which case you should find the necessary file (tabbrowser.xml) in browser.jar.

See https://developer.mozilla.org/En/Build_Documentation for help on pulling and building the source.

Comment 7

[Nochum Sossonko [:Natch]]

(In reply to comment #4)
> I think this should be fixed by the patch in bug 465184 (onemen.one, can you
> confirm?)

It doesn't fix it as is, although if the flavor is extended to input fields it probably can.

Comment 8

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

Fixed by bug 471499

Comment 9

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

Verified on trunk and 1.9.1 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090125
Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090125052901

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre)
Gecko/20090126 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090126020313

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125
Minefield/3.2a1pre ID:20090125034316

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090126 Minefield/3.2a1pre ID:20090126020316

Comment 10

[u279076]

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