Closed Bug 36867 Opened 25 years ago Closed 19 years ago

Drag link out of window, then back in, allows drop in content area

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Product:
Core
Component:
DOM: Copy & Paste and Drag & Drop
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: jmd, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: topembed+)

On linux (doesn't happen on win32), if you click on a link, but after click down change your mind, you normally would just move your pointer off the link and release. On win32, and 4.7, this has the correct affect. On recent linux mozilla builds, you end up DnD'ing the link into the current window, which loads it anyway, which is what you are trying to avoid. No one is going to DnD a link into its own window, this needs to be disabled.
Confirming bug in recenty M16 nightlies (e.g. 2000042113), it's fairly annoying and doesn't happen in Netscape 4.x
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Browser-General → XP Toolkit/Widgets
reassigning.
Assignee: asadotzler → trudelle
QA Contact: jelwell → jrgm
reassigning to blizzard per pav. agree that disallowing a drop on the source page makes more sense, and is consistent prev. versions.
Assignee: trudelle → blizzard
--CORRECTION-- It seems todays win32 now exhibits this behavior. Going back some, April 15 is the first build I have that doesn't, but that was M15, I'm thining DND wasen't imp.'d then. Marking all OS. IE5 does not allow this eaither, it draws the "no" sign (O with a \ through) when you try, allowing you to cancel your click. Note that NS4 handled this quite ambiguously on Linux, at least...the DND icon kind of just shrunk into the backround, not really making it clear, what, if anything, you just did.
OS: Linux → All
Assigning to pink since it sounds like it's an XP problem.
Assignee: blizzard → pinkerton
the easiest thing would be to check that the url being dropped was the same as the page being currently displayed and just do nothing (but the drop would still look as if it was accepted). How does this sound?
Status: NEW → ASSIGNED
Target Milestone: --- → M20
its acceptable enough i suppose. on one hand, it makes sense, you are loading what you droped into the main window, its just doing it without any network traffic cause its already there. on another hand, IE5's 'no' symbol clearly tells the user (well, a user who's familiar with microsoft icon symbols) that releasing the button there will have no action.
No, that's not right. Say page A contains a link to page B. You shouldn't be able to drag the link to page B into a blank area of page A. IMO this should be fixed before M20, because it's very visible and fairly annoying.
err, oh ya. I don't think i was thinking of the right bug in my earlier reply. what we want is: any link in 'Window X' should not be openable by droping it inside 'Window X' maybe if it's draged to the location bar, it should open. but really, why not just click on it? note ns4.7linux behavior: draging a link to location bar copies it there, IN THE MIDDLE OF WHAT WAS ALREADY THERE. this is quite useless. ie: http://bugzihttp://bugzilla.mozilla.org/bug_status.htmllla.mozilla.org/show_bug.cgi?id=36867
Actually, [drag link to location bar --> open link in this window] can be useful: it ignores target= values. The silly NS4x behavior you mentioned still happens in mozilla when you drag the "url icon" (icon to the left of the url in the location bar) into the location bar, but there's probably a bug for that somewhere already.
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Uhm... all this recheduling is getting nuts. You're gonna end up with mozilla-1.0 alot quicker like this, and it's going to be choped to pieces when reviewers compare it to IE5.5. This bug is a must-fix, it's a major impact on usability, usability netscape has had probably since it was called mosaic.
Dragging from the Bookmark toolbar to the content area is an example of useful dnd within the window. Dragging within the content area (not counting form inputs) should have no effect. See also bug 40911.
If possible, this bug should be generalized to `Drag-and-drop where {source == target} should have no effect', and it should be fixed for the general case. Otherwise we're going to be finding special cases all over the place, such as this bug and bug 40911, and implementing half-baked fixes each time.
wrong-o! what if i want to rearrange bookmarks w/in the personal toolbar? src = dest. or within the same folder in the bookmarks window. again, src = dest. we can't generalize this. it's on a case by case basis.
The personal toolbar, and a folder in the bookmarks window, each have several drag targets -- one between each two items in the toolbar/folder. So when you do that drag, source != destination, unless you happen to drag the bookmark to exactly the same position as you dragged it from. In a Composer content frame, you have lots of drag targets, one between each two characters/objects on the page (except for the selected content, which can and should be treated as a single drag target). In a browser content frame (which this bug is about), you usually only have one drag target (the page), but may have additional drag targets within it (TEXTAREAs and INPUTs). Without a fix for the general case, dragging a bookmark to exactly the same place in the bookmarks toolbar as it was before (to pick just one example) would result in some completely unnecessary CPU work at best, and some completely unnecessary file I/O at worst, as the bookmark was rewritten into exactly the same place in the bookmarks file. Like many of the (source == destination) d-n-d bugs, it would be a performance bug only and would be very difficult to detect unless you were actually reading the Mozilla source code.
Browser D&D. QA Assigning to self.
QA Contact: jrgm → elig
*** Bug 44414 has been marked as a duplicate of this bug. ***
This seems to be no longer an issue. Dragging a link within one window has the desired effect (nothing) on Linux build 2000-08-17-13.
yep. i'd say this bug is fixed. is there another bug for making dragging to the location bar open the link instead of inserting the link into the url that's already there?
Keywords: qawanted
QA Contact: elig
This is still happening on 2000090820, Mac OS 9.0 ... but only if you drag the link out of the window, and then (in the same drag) back into the window again. Jeffrey, Jesse, can you see if those (slightly more complicated) steps still produce the wrong effect on Windows and Linux too? [Someone with access to Windows, Mac OS, and Linux needs to take QA for this bug]
Yes it is still busted on Linux. Drag out of and back into window, Mozilla follows the dropped link. Linux 2000-09-10-22 debug build.
qa->jrgm
QA Contact: jrgm
yeah, the "out of window then back in" problem we'll have to live with forever, I think. It's just a side-effect of how we turn on/off d&d w/in the toolkit when leaving/entering windows. is there anything else left in this bug besides that?
Dragging back into the window is the most obvious way of cancelling an out-of-window drag (and in some situations/platforms, it may be the *only* way). So to leave this unfixed `forever' really ain't good enough.
I'll try to come up with a solution, but no promises.
Summary: draganddrop link incorectly opening page → Drag link out of window, then back in, allows drop in content area
Target Milestone: Future → mozilla0.9
*** Bug 47424 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9 → Future
-> drag-and-drop, cc dnd owner.
Component: XP Toolkit/Widgets → XP Apps: Drag and Drop
In a frameset, if the mouse is dragged or jarred slightly while clicking on a link, the URL will replace the top/parent frame with the contents of the page in URL. If this is a feature add, then there should be a way to intercept the ondrag event. This only happens in a frameset. This happened on Windows 2000.
*** Bug 79359 has been marked as a duplicate of this bug. ***
I filed bug 83963 for the frameset issue. Does this one bug block that one? Adding some keywords.
Keywords: 4xp, correctness, mozilla1.0
Hardware: PC → All
I'm seeing this in build 2001091303
*** Bug 142058 has been marked as a duplicate of this bug. ***
Keywords: topembed → topembed-
Marking as topembed+ per EDT triage.
Keywords: topembed- → topembed+
over to saari
Assignee: pinkerton → saari
Status: ASSIGNED → NEW
pinkerton sez: you'd have to store, in the drag data, the window where the drag originated so it sounds doable at least ->bryner
Assignee: saari → bryner
I actually like this feature.
Discussed in topembed bug triage. Can we get an updated milestone please?
This behavior is actually very useful, as it allows the user to force a link to open in the current tab (or window). Other browsers (like Opera and several IE-derivatives) also provide the same functionality. Prog.
*** Bug 243705 has been marked as a duplicate of this bug. ***
I find this behaviour more illogical than "useful". It's absolutely strange that I can move the content out of the content area and then back to have drag&drop to the source-place enabled!
I can reproduce this with Firefox 0.8 under Windows95.
If you really would like to keep this "feature", you should directly after dragging the object show the enabled pointer, so that it is not necessary to first move the content to anywhere and the back! So, I think, this would not look so buggy...
(In reply to comment #41) > This behavior is actually very useful, as it allows the user to force a link to > open in the current tab (or window). Other browsers (like Opera and several > IE-derivatives) also provide the same functionality. > > Prog. You can just drag&drop the link to the tab. So there is no need to drop it back to the window.
(In reply to comment #46) > (In reply to comment #41) If the here decribed problem would be fixed, this would only not be possible if you only have one site open, so that the tab-bar is hidden. But I think this problem better would be solved by a feature to always show the tab-bar.
(In reply to comment #46) > You can just drag&drop the link to the tab. So there is no need to drop it > back to the window. What if the user only views a single page and there is no tab-bar? Use the Go button? It's off by default and many users dislike it. (In reply to comment #47) > But I think this problem better would be solved by a feature to always show > the tab-bar. This feature already exists (under Navigator -> Tabbed Browsing), but again, it's off by default and many users prefer it that way. To sum it up, dragging a link back to the content window is useful. There's really nothing to fix here as it isn't broken. Prog.
to prognathous: In Firefox such a feature does NOT exist!!! This behavioutr _IS_ a bug! What you think about Comment #45 !?
(In reply to comment #45) typing error: "to anywhere and the back" -> "to anywhere and then back"
(In reply to comment #49) > In Firefox such a feature does NOT exist!!! Yes it does. At least on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 (see Advanced -> Browsing -> Hide the tab bar...) Moreover, this is a Seamonky bug, not a Firefox one. > This behavioutr _IS_ a bug! In the bugzilla sense of the word it is, Bug# 36867, but since this behavior is highly useful, the bug should be WONTFIXED. > What you think about Comment #45 !? Your suggestion was already implemented in Mozilla in the past - and removed. See Bug 40911 and Bug 227221. Prog.
You might want to read this very related bug/suggestion as well: http://bugzilla.mozilla.org/show_bug.cgi?id=227221
Oops sorry, I now see prognathous already posted a link before me. Anyway, I think it would be very useful as long as people can turn it off/on and you don't have to drag-drop with such a long move.
Blocks: 243963
I think I have found the ultimate solution for this problem: ;-) - dix the bug - change the drag&drop behaviour of the URL-field, so that when dropping links there they are directly opened and not just pasted as text like it is currently handled. IE behaves so. This would keep the feature to open links in the same tab, also if the tab-bar is hidden because just one tab is open. I really think this is a great solution! What do you mean?
(In reply to comment #54) typing error: "- dix the bug" -> "- fix the bug"
Opening links by dragging them to the address bar is suggested in Bug 57228 and Bug 111869. It's a reasonable solution, though perhaps a bit slower than dropping links in the content area (as one have to aim the drop in the much smaller area of the address bar). A better solution, IMHO, would be to back out Bug 40911 and allow links to be dropped in the content area, without first being dragged outside of it. Prog.
I also agree that Comment #56 is a good solution. I already have told the same in Comment #45. But if you plan to fix it like described in Comment #54, please don't forget to make sure, that just moving the link over another frame also should not enable the drop-operation.
(In reply to comment #45) (In reply to comment #56) I just have seen that Links can be drag&dropped to the Go-button, so that they open directly. So this bug can be fixed without losing features! So I revoke comment #45. But I still think that the suggestions in Comment #54 should be implemented to also have the feature to open links in the same tab if the tab bar is hidden and the Go-button is not placed in the navigation bar. So this bug can be fixed ...
I just have seen, that Linux Firefox 0.9.1 has not this bug! So why is OS "All" selected here?
The bug is marked as All/All due to comment #21 and comment #22. (In reply to comment #58) > I just have seen that Links can be drag&dropped to the Go-button, so that they > open directly. We've already discussed this previously, see comment $48 Prog.
That was supposed to be comment #48 of course. Anyway, I'll save you the time to look it up, here the relevant quote: > What if the user only views a single page and there is no tab-bar? > Use the Go button? It's off by default and many users dislike it. Sorry for the spam, Prog.
(In reply to comment #61) > > What if the user only views a single page and there is no tab-bar? > > Use the Go button? It's off by default and many users dislike it. Links can be forced to be opened in new tab/window by holding down CTRL/SHIFT while clicking them. Therfore, to solve this problem, I think it would be consequent to introduce also a special key to force links to open in the current tab. What do you mean?
completion of comment #62: Bug 251693 is about such a key and a context menu item to open links in the current tab. I think this is the solution, so that this bug can be fixed without losing features.
Since Firefox has the same problems... Is it therefore necessary to submit a own bug concerning these problems with Product "Firefox" ???
Maybe this bug is related to bug 255863. Please check this.
In Linux-Firefox links open directly if drag_and_dropped into the addressbar, but not in windows. (I don't know if this is the same in Mozilla.) So this has to be fixed for Windows-Firefox to keep consistency. (bug 259107 and bug 111869) If this inconsistency is fixed, this bug can also be fixes without losing features.
(In reply to comment #66) typing error: fixes->fixed
Re comment #60, MacOS 9 is no longer supported. Can anyone with Linux confirm whether or not the bug has been fixed? It certainly has on Windows so I think at the very least, this bug should be set to Linux and closed if it's fixed.
this got fixed for Mozilla 1.7.6 as part of bug 285438
Status: NEW → RESOLVED
Closed: 19 years ago
Depends on: 285438
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.