Closed Bug 471955 Opened 15 years ago Closed 15 years ago

Drag and drop url onto explorer/desktop fails.

Categories

(Firefox :: Tabbed Browser, defect, P2)

3.5 Branch
x86
Windows Vista
defect

Tracking

()

RESOLVED DUPLICATE of bug 478070
Firefox 3.6a1

People

(Reporter: Dpeelen, Assigned: asaf)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081227 Minefield/3.2a1pre

In firefox 3.0, i could drag a tab onto a explorer window or my desktop, to make a shortcut to it.

Since firefox 3.1, this result in a new browser window, as tear of tab kicks in.
Now this is about the one and only sensible use case where tear of tab should kick in, but the old behaviour is still lost.

It would make sense it it was possible to make a shortcut by selecting the address bar, and drag the url onto the desktop. (google chrome works like this).

Reproducible: Always

Steps to Reproduce:
1. Select current url
2. Drag it outside firefox, drop it onto the desktop
3. Create shortcut
Actual Results:  
No shortcut created.

Expected Results:  
A shortcut created.
Confirmed on Windows XP. I don't know if somewhere lives a duplicate.
Blocks: 225680
Component: Drag and Drop → Tabbed Browser
Keywords: regression
Product: Core → Firefox
QA Contact: drag-drop → tabbed.browser
Version: unspecified → 3.1 Branch
Using the steps in comment 0 doesn't even work with Firefox 3.0 on XP. You have to drag the favicon and not the selected URL onto the desktop to create a new shortcut. I would tend to WFM.
Keywords: regression
Ah true, I've always been dragging tabs, but using the favicon indeed works.

Still, dragging a url onto the bookmark bar works (creates bookmark).
Dragging the favicon onto the bookmark bar works.
Dragging a bookmark onto the desktop works.
Dragging a url onto the desktop fails.

Even when there is a workaround, and thus this is not really a regression from tear off tab, still looks like unexpected behaviour that could be improved.
(In reply to comment #3)
> Still, dragging a url onto the bookmark bar works (creates bookmark).

Good point! I can confirm that it is a regression. This action isn't possible anymore.

Dorus, would you like to run a regression test? We need to know when it has been regressed. If yes, try to narrow down the range by using the nightly builds of mozilla-1.9.1 or mozilla-central (before 2008-12-01). All the builds can be found here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/

That would really help us!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well oops, only tested that in firefox 3 when i wrote that.

Some quick regresion checking shows:

All working:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080919032843 Minefield/3.1b1pre

Cursor 'animation' stil working in this one, but doesn't create a bookmark.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080920033605 Minefield/3.1b1pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081011 Minefield/3.1b2pre

In this one, i can't even drag the text in the url bar anymore at all
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081018 Minefield/3.1b2pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre

In this one, i can drag again, but not onto bookmark bar, shows blocked cursor (= current behaviour also):
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081022 Minefield/3.1b2pre

That's the best i could do quickly with what i already had locally. Odly and lucky i already had the first 2 regressing builds on my pc. Hope this helps. (ps. now this bug is high jacked by this regresion, should i create a new one for the 'drag url onto desktop' feature?)
Severity: minor → normal
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 471499, 475066
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Verified with:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre ID:20090127032613

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090126 Shiretoko/3.1b3pre ID:20090126033406

I cannot find an existing test for now. Lets add the in-litmus flag.
Status: RESOLVED → VERIFIED
Flags: in-litmus?
I can confirm that dragging a TAB onto the desktop now works.

However, neither dragging the url onto the bookmark bar (did work on FF3.0, and in the regression range in comment #5) or dragging the url onto the desktop (never worked, but would be a nice to have, the reason i made this bug). Are these 2 problems known? And do they have there own bug?

If not i will make them myself soon :)
(In reply to comment #7)
> dragging the url onto the bookmark bar (did work on FF3.0, and
> in the regression range in comment #5)

See bug 475045.
(In reply to comment #7) 
> However, neither dragging the url onto the bookmark bar (did work on FF3.0, and
> in the regression range in comment #5) or dragging the url onto the desktop
> (never worked, but would be a nice to have, the reason i made this bug). Are
> these 2 problems known? And do they have there own bug?

Dorus, what's the source of your drag&drop action? Does the hint from Dao clarifies it for you?
Flags: in-litmus?
Problem 1 is about selecting the URL in the URL bar. Then dragging it to the bookmark bar. This is almost the same as bug 475045, where a (non linked) url from a web page is dragged.
However, i did find another regresion range as there, so i'm not 100% sure it's the same problem.

Problem 2 is not really a problem, but more a request from my side. Namely dragging a URL from the URL bar onto the desktop, and make a short cut of that URL.

Guess the confusion comes from the fact i'm selecting the url in the url bar.
The reason that's useful is because i can then select a part of the url (for example "https://bugzilla.mozilla.org/" instead of "https://bugzilla.mozilla.org/show_bug.cgi?id=471955" and make a bookmark/short cut of only that. Also, it would make sense if this was possible, as it now only gives a forbidden cursor. Where draging the url onto the tab bar does create either a new tab, or reload the current tab with the used url.
(In reply to comment #10)
> However, i did find another regresion range as there, so i'm not 100% sure it's
> the same problem.

Can you mention this on bug 475045? Also give the regression range. So we can try to figure it out there.
 
> Problem 2 is not really a problem, but more a request from my side. Namely
> dragging a URL from the URL bar onto the desktop, and make a short cut of that
> URL.

Mmh that works for OS X and was fixed in bug 388522. Could you check if it has the same regression range as you can see? If yes please file a new bug and cc me. Thanks.
Status: VERIFIED → REOPENED
Keywords: verified1.9.1
Resolution: FIXED → ---
Target Milestone: Firefox 3.2a1 → ---
Blocks: 475066
No longer depends on: 475066
1. Select current url
2. Drag it outside firefox, drop it onto the desktop

On trunk, the expected result is a window, not a shortcut. If this bug is about going back to the later, it's not a bug.
(In reply to comment #12)
> 1. Select current url
> 2. Drag it outside firefox, drop it onto the desktop
> 
> On trunk, the expected result is a window, not a shortcut. If this bug is about
> going back to the later, it's not a bug.

If you select the URL from the location bar, it should not create a new window - that should only happen if you drag the tab source. I would say that this is a bug, indeed. Dragging the URL text to the desktop should still create a shortcut.

It does this for me, now, on branch, though, so is this WFM?
Assignee: nobody → mano
Flags: blocking-firefox3.1?
Henrik, I need clear STR here with regression range if any. I tend to believe that it's not a regression at all, but I might be wrong.
Just tested the following steps:

1. Load a page
2. Highlight the URL and drag the text to the desktop

OSX - works as expected, creates a shortcut
Windows - shows a "cannot drop" indicator, doesn't do anything
Linux - creates a text file with the URL text in it

Dragging the favicon, however, creates a shortcut. This isn't a regression; same behaviour can be observed in Firefox 3.0.x ... it is, however, wrong. In all cases, dragging the URL or favicon should create a shortcut on the desktop.
Keywords: regression
Priority: -- → P2
I could take this.
I'm already working on a fix (for comment 15)
Status: REOPENED → ASSIGNED
Target Milestone: --- → Firefox 3.2a1
Please notice i opened bug 478070 as per comment #11. That might be a duplicate of this one by now.
Would take a patch, but since this isn't a regression, doesn't block. Just, you know, sucks.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
how about using a modifier such as ALT to make a shortcut of a dragged tab?
this is similar to the behavior of windows explorer
That is only useful because the default behaviour of windows explorer is to move when dragged. As firefox only gives a error sign currently, there is no reason to hide this behind the ALT. Unless you got better behaviour in mind for non-ALT dragging of course.


Also, please keep the behaviour similar between platforms.
(In reply to comment #21)
> That is only useful because the default behaviour of windows explorer is to
> move when dragged. As firefox only gives a error sign currently, there is no
> reason to hide this behind the ALT. Unless you got better behaviour in mind for
> non-ALT dragging of course.
> 

i was referring to the dragging of the tab itself (not the url) as discussed in the bug description
No longer blocks: 475066
Flags: blocking-firefox3.6?
while this bug is still relevant for 3.5.2,
it seems to be fixed in 3.6a2
Status: ASSIGNED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → DUPLICATE
Flags: blocking-firefox3.6?
You need to log in before you can comment on or make changes to this bug.