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)
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.
Comment 1•15 years ago
|
||
Confirmed on Windows XP. I don't know if somewhere lives a duplicate.
Blocks: 225680
Updated•15 years ago
|
Component: Drag and Drop → Tabbed Browser
Keywords: regression
Product: Core → Firefox
QA Contact: drag-drop → tabbed.browser
Version: unspecified → 3.1 Branch
Comment 2•15 years ago
|
||
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
Reporter | ||
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
(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!
Reporter | ||
Comment 5•15 years ago
|
||
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?)
Updated•15 years ago
|
Severity: minor → normal
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: regressionwindow-wanted → fixed1.9.1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Comment 6•15 years ago
|
||
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.
Reporter | ||
Comment 7•15 years ago
|
||
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 :)
Comment 8•15 years ago
|
||
(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.
Comment 9•15 years ago
|
||
(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?
Updated•15 years ago
|
Flags: in-litmus?
Reporter | ||
Comment 10•15 years ago
|
||
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.
Comment 11•15 years ago
|
||
(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.
Updated•15 years ago
|
Status: VERIFIED → REOPENED
Keywords: verified1.9.1
Resolution: FIXED → ---
Target Milestone: Firefox 3.2a1 → ---
Updated•15 years ago
|
Assignee | ||
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
(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?
Assignee | ||
Comment 14•15 years ago
|
||
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.
Comment 15•15 years ago
|
||
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
Comment 16•15 years ago
|
||
I could take this.
Assignee | ||
Comment 17•15 years ago
|
||
I'm already working on a fix (for comment 15)
Status: REOPENED → ASSIGNED
Target Milestone: --- → Firefox 3.2a1
Reporter | ||
Comment 18•15 years ago
|
||
Please notice i opened bug 478070 as per comment #11. That might be a duplicate of this one by now.
Comment 19•15 years ago
|
||
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-
Comment 20•15 years ago
|
||
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
Reporter | ||
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
(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
Updated•15 years ago
|
Flags: blocking-firefox3.6?
Comment 23•15 years ago
|
||
while this bug is still relevant for 3.5.2, it seems to be fixed in 3.6a2
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Flags: blocking-firefox3.6?
You need to log in
before you can comment on or make changes to this bug.
Description
•