Closed Bug 465346 Opened 16 years ago Closed 16 years ago

tab drag and drop (dnd, detach) to new window should have a bigger threshold to prevent accidental detaching

Categories

(Firefox :: Tabbed Browser, defect, P1)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.6a1

People

(Reporter: ted, Assigned: asaf)

References

Details

(Keywords: verified1.9.1, Whiteboard: [fixed by bug 471499])

My biggest complaint with "drag tab to create a new window" is that if I click a tab and accidentally drag a little bit, I wind up with a new window. I'd like it to have a threshold, because this happens to me all the time. If I drag just a few pixels it shouldn't create a new window. (Possibly related to bug 465184, but I felt it deserved its own bug.)
This is pretty much bug 465184, we do take care of dragging the tab (to some other place on the tabbbar) just a few pixels (1/2 height of a tab, i think) above the tabbar.
Feel free to dupe over if you think that bug covers it.
Please test again in a build done after the second checkin for the original bug and let me know what do you think.
Just tested this with the latest hourly: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081119 Minefield/3.1b2pre This problem (if I understand it) is still present. Drag a tab a little inside it's own window and it will create a new one. This could cause some annoyance to many people if that isn't how it is meant to work.
Flags: blocking-firefox3.1?
Using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre ID:20081120033739" with all extensions and plug-ins disabled. This problem is even worse for tablet users as humans are not machines and thus their hands are not stable, when one clicks on a tab that he/she wants to activate, it will drag&drop to on top of the tab he/she is trying to activate and open a new window. What is the reasoning for opening a new window when a tab is drag&dropped on to itself (I can see the benefits of detaching a tab to it's own window window by dragging it to content area, but not to the tab switching area, that's just unthought of side-effect I believe). Could it be made so, that when dragging and dropping a tab inside the tab switching area, a new window will not be opened ?
In terms of vertical sensitivity, I think we should probably use half the tab height (so you have to drag the tab at least half way down past the bottom/left/right edge of the tab strip)
Is there really a need for any threshold? If it's implemented, it's value won't be right for half of the users and then theres probably another new about:config entry.. No-ones hand moves that much when they click on a tab that it'll go outside the tab area. Just disable new window opening with DnD on that area and the problem vanished with minimal modifications.
By "threshold" I just meant "ignore small accidental drags". Beltzner's suggestion sounds about right, but I think if we just ignored drags where the drop was inside the original tab area we'd be fine too.
That might be enough - most of my accidental drags are caused when my touchpad registers a "mouse-down and drag" action instead of a "mouse-click and move" one, or the mouse moves just the tiniest bit while clicking.
(In reply to comment #10) > Is there really a need for any threshold? If it's implemented, it's value won't > be right for half of the users and then theres probably another new > about:config entry.. No-ones hand moves that much when they click on a tab that > it'll go outside the tab area. Just disable new window opening with DnD on that > area and the problem vanished with minimal modifications. I never suggested an about:config entry. I suggested that we get a sensible value and use it. While you might be very accurate with your mouse, we can't depend on everyone (or everyone's hardware, a bigger issue when you get into touch screens) to be that accurate. (In reply to comment #11) > By "threshold" I just meant "ignore small accidental drags". Beltzner's > suggestion sounds about right, but I think if we just ignored drags where the > drop was inside the original tab area we'd be fine too. Yeah, that sounds right. BTW, the better way to do this might be to register the tabstrip + 50% tab height as a valid drop point for inserting a tab on the tabstrip. That way when pinning a tab from window A onto window B, the user has a larger target to play with.
(In reply to comment #11) > ..., but I think if we just ignored drags where the > drop was inside the original tab area we'd be fine too. This to me seems most sensible and intuitive. In fact, I believe it would be even more intuitive that only the content area of a given browser window would be a valid drag area to create a new window--except where the drop is on a textarea. Other actions, like dragging the tab to the desktop, a folder, or another browser window, to create a shortcut or load the link, as per original behavior, is more intuitive. The current implementation makes it impossible to drag a tab to the bookmark toolbar to bookmark it. This does not strike me as intuitive
(In reply to comment #14) > The current implementation makes it impossible to drag a tab to the bookmark > toolbar to bookmark it. This does not strike me as intuitive That's not intended: see bug 465256 (which should be fixed now)
(In reply to comment #15) > That's not intended: see bug 465256 (which should be fixed now) Wrong bug. That one is for dragging a bookmark within bookmark toolbar. There's no fix for what I mentioned.
right, what you mention is more like bug 465332
OS: Windows XP → All
Hardware: PC → All
I think it would be better to have "detach" rather than dnd in the title so that people find this bug more easily and dont' enter duplicate.
Summary: tab dnd to new window should have a threshold → tab drag and drop (dnd) to new window should have a bigger threshold to prevent accidental detaching
This bug is getting really annoying while working with the latest nightly builds. When you are moving the mouse fast over a tab and click to open it, this tab is always deteached. Further it takes about 1s until the new windows is visible.
Summary: tab drag and drop (dnd) to new window should have a bigger threshold to prevent accidental detaching → tab drag and drop (dnd, detach) to new window should have a bigger threshold to prevent accidental detaching
Assignee: nobody → mano
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P1
Creating a new window with the tab should only happen when the user drags the tab outside the current window, because then the intention is really to create a new window. I fully agree with comment #22, the current behavior is very annoying (even for an advanced user like myself).
(In reply to comment #24) +1 Dragging a tab onto itself is, intuitively a NOP. The new window is unexpected. I like Alfred's suggestion best, it was certainly my initial expectation. Possible (more complicated) alternative: have an icon appear that you can drag onto to create a new window.
I will say further that I will be working in an entirely different tab, and another tab will seemingly spontaneously detach with just a fast mouse movement - but not near the tab bar. This has started happening with 3.1b2 . 3.1b1 did not exhibit this behavior at all. 3.1b2 does this when working withing Firefox and creating and closing tabs and then working in them about once every 3 minutes. Very annoying.
I also run into the same issues as Comment #26. Especially if, after switching to another tab (and it not detaching) I quickly the content in that page, with my mouse wheel. Suddenly the tab detaches. I also randomly get detaching when middle-clicking a link to open it in a new tab. The link instead opens in a new window. None of the above issues can be purposely reproduced. They all happen randomly, but he happen nonetheless. So I wonder if that tab detach patch is not properly initializing some variables and is thus working with garbage input. Either that or Tracemonkey.
The tab detach drives me crazy. In a lot of cases all I do is click (at least I think I do) and the tab rips to a new window. The threshold needs to be the tab height at least, so the user is obviously doing the operation.
Confirming Comment #33, I've had three tabs tear off today just by clicking them (I think always the one on the far right). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081223 Minefield/3.2a1pre
Comment #33 explains EXACTLY what's been constantly happening to me and others that have tried the beta. More people I personally know are being annoyed to the point of returning to a previous version than enjoying/finding any use for this feature.
ditto Comment #33, When I have multiple tabs open and want to move quickly from one to another I invariably end up with new windows and, of course, the original tabs have closed. It's a real bind having to reopen them in my main window. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081223 Minefield/3.2a1pre ID:20081223034717
Please just use the vote link ( https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=465346#vote_465346 ) for me too style comments, commenting like that is pretty useless, see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html . This bug is blocking the release of firefox and will be fixed before the final version is delivered.
hmm could be. I have been switching between 2 tabs all day today and this bug is driving me absolutely insane...or insan(er)... I also think it could be related to some kind of queue delay of some kind, especially if my PC is busy doing some work. It seems to me that sometimes I click and then move the mouse quickly but the application thinks I've moved in between the mouse down and mouse up signals when it really should have been an up-down-move-move-move sequene.
Please do not spam this bug any further then it already has been. No other confirmations, suggestions, complaining, or any other types of comments are needed unless you are supplying a patch to fix the bug. This bug has been accepted to block the final release of Firefox 3.1. Everyone knows how annoying this is and the developers know this bug needs to be fixed and they are going to fix it.
Whiteboard: [Read comment #40 before commenting]
(In reply to comment #1) > This is pretty much bug 465184, we do take care of dragging the tab (to some > other place on the tabbbar) just a few pixels (1/2 height of a tab, i think) > above the tabbar. Nope. Not really. (In reply to comment #2) > Feel free to dupe over if you think that bug covers it. Bug 465184 cannot fix this bug. I'm running a build with the current Bug 465184 patch included, and I still get the occasional detach if I very quickly scroll (with my scroll wheel) immediately after switching tabs. There is also the case where clicking a link, immediately after switching to a tab, will detach the tab while loading the clicked link. Bug 465184 will not fix this either. I believe both the detach on scroll and detach on link click issues are related; and, if this bug does not fix them, maybe Bug 225680 needs to be revisited. I suppose the detach target should have been made very specific in the first place.
I'm using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090104 Shiretoko/3.1b3pre and tab tearing is way TOO sensitive. If I touch a tab wrong, all of a sudden I've got a new window opened.
Whiteboard: [Read comment #40 before commenting] → [patch on bug 471499][Read comment #40 before commenting]
Fixed by bug 471499
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Whiteboard: [patch on bug 471499][Read comment #40 before commenting] → [fixed by bug 471499]
Target Milestone: --- → Firefox 3.2a1
verified FIXED on Shiretoko: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090513 Shiretoko/3.5b5pre ID:20090513034609
Keywords: fixed1.9.1 → verified1.9.1
This issue is not solved yet. Whenever the browser hangs, this feature is activated even if the user drags the tab only a fraction of a millimeter. Also many accidental dragging occur even when the browser does not hang. Why do we need this 'dragging feature' at all? The user can move the tab to a new window by right-clicking the mouse and choosing "Move to new window". Please cancel this very annoying feature which is actually a bug.

Dirty patching by addons that instantly undo the action is no solution, please add some trigger delay/toggle in about:config for this very annoying feature.

This happens often, it's quite annoying. Would prefer if the drag and drop could be disabled and have a Detach option when right clicking a tab.

Ok there's Move To New Window. That's cool. Also I think the drag and dropping is needed in cases where the window is not maximized, which is when I often intend to drag the tab to another window. But drag and dropping is annoying on maximized windows.

manuelchaves, could you please file a new bug?
This one is already closed.

Flags: needinfo?(manuelchaves)
You need to log in before you can comment on or make changes to this bug.