Open Bug 727420 Opened 12 years ago Updated 1 year ago

Tab tearing is too sensitive. Tabs frequently moved to new window accidentally.

Categories

(Firefox :: Tabbed Browser, enhancement)

Product:
Firefox
Component:
Tabbed Browser
Type:
enhancement

Tracking

()

People

(Reporter: markleci, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: access) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120208012847

Steps to reproduce:

I have noticed that since upgrading to FF10/11 (I use different versions on different machines) that the tab tearing threshold seems to have changed.


Actual results:

 I get incidents of accidentally moving tabs to new windows multiple times per day on each machine. There is no about:config setting either to change the threshold or disable tearing so the behaviour cannot be modified in any way. 


Expected results:

This has been bugged multiple times before and supposedly fixed. A better solution would be to allow either the threshold to be configurable or allow tearing to be disabled, or both!
I found out some more information on this. I found that if I drag and drop a tab (in the same place or to reposition it) then click on another program window (e.g. VLC) within a second or two, the tab is moved to a new window. Not sure if I should change the bug title based on this or not.
Bug 616130 covers not being able to disable the feature.  I'd prefer a fix for the "too sensitive" part if that's possible :)
Summary: Tab tearing in FF10 & 11 is too sensitive and cannot be disabled → Tab tearing in FF10 & 11 is too sensitive
Component: Untriaged → Tabbed Browser
I am experiencing this issue in Firefox 23. Running Firefox on 2nd monitor, multiple times per day I reorder tabs. When doing this inadvertently I move the mouse down to the small gap between the tabs and the address bar. Doing this causes my tab that I was dragging to be moved to a new window on my 1st monitor instead of reordering to the position I wanted it to move to.
I've been noticing the same problem, especially with pinned tabs. It gets really annoying. I am using Win7 so this isn't just an OS X issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
Since I'm seeing this problem in FF24, I'm removing FF version notes from title.
Summary: Tab tearing in FF10 & 11 is too sensitive → Tab tearing is too sensitive. Tabs frequently moved to new window accidentally.
I am seeing this as well. Using the disable plugin https://addons.mozilla.org/en-US/firefox/addon/bug489729-disable-detach-and-t/
I wonder what has changed, but this problem is quite recent for me. While it never occurred before August 2015, it now occurs quite frequently, e.g. at least 3 times today.
I got this several times a day now on Firefox 46 on Linux. It seldom happened before.
It mainly happens when I am on a page and middle-click a link that loads a heavy page. While the tab is loading, I click on it. Nothing happens for several seconds, and when the page has loaded, boom, the tab detaches itself.

When the tab is already loaded, I don't often face that behavior. I'm trying to find a way to spy mouse events. Just for the record, Firefox 46 on Linux introduced the switch from GTK 2 to GTK 3. I'm also using Ubuntu 16.04 with the default graphics environment and theme (Unity/Ambiance).
I experience this annoyance many times a day. It is terrible. 
I'm near to getting-rid of FF for this reason.
This problem was mitigated with the 'disable' plugin, and the response of developers at the time was "use that plugin".

However, that plugin no longer works with FF> 0.52, and therefore no one has a solution to mitigate this frustrating, reoccurring, and persistant issue for many users.

Can someone PLEASE at least provide an about:config way to disable the tearing/detaching of tabs by dragging, completely?  Or perhaps a sensitivity adjustment?  This happens to me many times per day...
It seems better for me on Ubuntu 18.04 with Gnome and Firefox 63.

I am also newly (last month or two, and worse during the last week or so) encountering this problem. I have not been able to notice what I am doing when this problem happens. I think all I am doing is clicking on a tab. It is always a surprise.

If I can provide more information I will post it here.

The problem is aggravated by a secondary problem: after the new window is created, there seems to be no easy way to get the tab in the new window back to the old window and then to delete the new window.

FF 65.0 (64bit), Windows 10 Home, HP laptop.

This happens to me also from time to time. A tab is opened to a new window when you drag it from tab bar onto the page, but when this happens, I'm not intentionally dragging, I'm just trying to click the tab, dragging happens by accident.

A setting to disable this in about:config would be nice.

fluks, there is a workaround, until Firefox is fixed: an addon called "Disable Tab Detach". Editorial: we should not wait for addons, we should fix bugs.

(In reply to David Spector from comment #17)

fluks, there is a workaround, until Firefox is fixed: an addon called "Disable Tab Detach". Editorial: we should not wait for addons, we should fix bugs.

Thanks. I would like to fix this, if adding about:config setting is accepted as a solution. I think I have read the developers aren't too eager to add them easily. The defect should affect many users to warrant adding a new setting. I don't think user telematry covers this, so how can we know?

I think a fairly good way to evaluate problems is to search the web for postings concerning them. Compare postings for different problems to get a feel for comparing them, bearing in mind that the number of postings tends also to increase with time.

The ideal solution to a problem is simply to fix it in such a way that new problems as a result of the fix are not reported. But if compatibility is an issue, if some people need the "problem" to happen, then about:config can be used. But when a problem affects many users, as this one does, using about: config is not so great, since we have to wait until someone complains before suggesting an about:config solution.

This is so annoying! Yeah, I'm one who now has tabs flying everywhere, or I need to keep toggling my addon disable off/on/off so that I can still tear when I want to. After my last update, it seems if I'm just clicking while getting focus on a tab and it moves a little, bam, the tabs off on it's own. Clearly something changed. Not sure if my zoom at 80% or something else aggravates the sensitivity?

As other point out, it's not about creating addons to disable tearing. That's a symptom of how bad it got that someone created an App to disable the new "feature" and people are adding it. Realize the number of frustrated people who remove Firefox vs. search for a Disable App, is probably orders of magnitude greater. I knew to look because nothing gets this frustrating without someone investing in a remedy.

I think what everyone really wants is "legacy_tear_setting=true". Those that need a tab to tear without actually dragging it off the can use the new way. Those that are older and fidgety will love going back to the sturdy legacy tabs. Or how about "fidgity_tear=false"? Sometimes I'm just so anxious to get to that new tab that my hand is still in motion while clicking to get focus. :)

I just did some experiments and if I drag a tab title down, it tears into a new window. Before I had to actually drag a tab outside the frame. So that can be the definition of "legacy" or "fidgity". If I move the mouse pointer from mid tab to just below the line (1/2 a tab height), it flies. I tried this in Chrome and I have to move the tab what would be imagined as one whole tab height distance. That's why my Chrome tabs don't fling around - they give me 1/2 height buffer over FF.

Probably someone should rethink this feature. Instead of using drag and drop to move tabs, perhaps "cut and paste" would be a better mechanism. Not everything should be done with the mouse, and in fact relying on the mouse ignores the needs of blind and visually impaired people.

Disable Tab Detach has 13 000 users, that should show this bug is a BUG and should be fixed ASAP :)

I stopped using Firefox for this exact reason + Bug 1368346 a few years back, but came back to Firefox because Chrome memfloods tens of GB of RAM a day with ~500 tabs

everyone reading this: Vote for this bug (in the Details section in the header of this page), maybe that will get more attention from devs

Been 4 years since my last comment, but somewhere along the way, this stopped being an issue (either it got better or I got used to it). Currently Using Firefox 70 on Fedora 30

This is a big issue for me! I use Win7.

This has been an issue for me for literally years now. I frequently switch Linux distros. Currently on Gentoo but I've used Arch this year, and in the past few years I've run OpenSuSE and Fedora and various others. With every single distro the tab tearoff is so broken that there is like a 30% chance that just clicking on a tab, without noticeably dragging my mouse, tears it off. It's like moving my hand by even one or two pixels is making it tear. 8 years for this bug and it's not even been assigned or gotten a response from a developer?

Should I just use a browser where bugs get fixed? I've signed up for this bug tracker out of frustration to add another report to this bug, even though if nobody fixed it with all the other replies, not like my report is going to change anything :/

I have another report on this bug - it may be more subtle. I have use the same Firefox setup (including addons, etc) and I noticed that my work PC, with latest FF, is OK. But my home FF still tears off all the time (and I added the addon that pulls them back unless I temporarily unlock it). I have no idea what might be different between the two and wonder if there's just something stuck somewhere. My thunderbird email tool would get the saved passwords stuck and it was similar - only seemed to be a corruption for some users.

There is clearly something else wrong here. Maybe someone that understands this will see that 1) we're not all crazy, 2) there is a bug related to tab tearing that is very frustrating for many, 3) if someone can suggest other things to try debugging this further (other than wipe out all your files and start over and see if that helps). Let's fix this and prevent it from happening to more people in the future. There's nothing else on my home PC that is hyper-sensitive to clicking.

Nobody should need to use the addon because it also breaks the ability to right click the tab and move it to a new window. Plus the visual effect of the tab being torn out, only for it to snap back, is about the most annoying thing ever (except for the tab tearoff being an issue in the first place).

raistlinmajere, I agree with you that the addon is not the best solution. However, the problems reported in this bug do exist and need to be fixed.

I use the addon every day and find that it works perfectly for me, since I prefer to run Firefox in only one window (containing many tabs). I never want to move a tab off the tab bar.

I am happy with all the bug fixes done to tabs and to saving/restoring tabs over the years, but this tear-off problem seems to be stuck in process for some reason. It is very strange to me that the bug has been here for 8 years and no one has felt to fix it as yet. Some people claim that Open Software is a practical way to develop software, but I just don't see it.

I would offer to fix it myself, but I have looked into contributing to Mozilla software and found the git and other administrative parts of it way too complex to be practical (the actual coding of features and fixes is not usually difficult, but it requires using build and other tools I'm not familiar with).

(In reply to timbo63 from comment #26)

I have another report on this bug - it may be more subtle. I have use the same Firefox setup (including addons, etc) and I noticed that my work PC, with latest FF, is OK. But my home FF still tears off all the time (and I added the addon that pulls them back unless I temporarily unlock it). I have no idea what might be different between the two and wonder if there's just something stuck somewhere. My thunderbird email tool would get the saved passwords stuck and it was similar - only seemed to be a corruption for some users.

I think that the bug is more likely to occur when the machine is slower or there are some processes (including Firefox itself, due to other tabs) that take resources. Thus a click (more precisely, the time during which the button is down) might appear to take longer (and the distance between the press and the release might appear to be larger), so that Firefox regards the click as a drag.

BTW, I've also noticed that when doing a text selection, the end of the text I selected is not always the same as the one I chose, as if Firefox was late to take the button release into account. This issue may have the same cause. Note: other applications do not have such an issue, i.e. this is specific to Firefox.

I'm also running into this bug, I just noticed how easy it is to split of the tab, I simply move my mouse to tab, over it I click and just because I move my mouse one pixel further the tab is dragged into another window.
It should be that I drag it at least a few centimetres, so that it's clear I'm dragging the tab to a new position.

Comment #30 alone is an argument for fixing this functionality NOW, in my opinion.

I've been a Firefox user under Windows 7 since early 2011 and first experienced this bug with FF 69 which has continued into FF 70.

The following extension will snap the detached tab back to its original window.

Also, it's possible to rearrange tabs without using the mouse:

  • Ctrl+Shift+Page Up to move the tab to the left.
  • Ctrl+Shift+Page Down to move the tab to the right.
  • Focus the address bar (e.g. Ctrl+L, Alt+D or F6), Shift+Tab repeatedly until the tab is focused (it gains a dotted rectangular border), then Ctrl+Shift+Home to move the tab to the beginning.
  • Same as above, but Ctrl+Shift+End to move the tab to the end.
Type: defect → enhancement
Keywords: access
See Also: → 616130

When you report a problem, please always specify your Firefox version and OS (on Linux it would also be useful to know the window manager in use).
If someone wants to spend time investigating his problem, here is the code that decides whether the tab should be detached:
https://searchfox.org/mozilla-central/rev/d061ba55ac76f41129618d638f4ef674303ec103/browser/base/content/tabbrowser-tabs.js#809
it's possible some of these calculations are wrong on specific cases (multiple screens, hi dpi, window managers...)
Personally, I can only reproduce this when the system is particularly busy (Firefox hanging), and that's not useful to debug this; it would be nice if someone that can easily reproduce in normal conditions, could try debugging the above code.

As far as I can tell from the symptoms, the problem is that Firefox is handling "mouse button released" events based on the position the cursor occupies at the time Firefox handles the event, rather than the "position when the event occurred" data that the windowing system event provides. (Which means that, the more Firefox janks, the greater the gap between the actual place the click was released and the place Firefox thinks it was released and the more likely it is that the bug gets triggered.)

It's sort of a mouse analogue to that Firefox 2.x bug on Linux where, if the browser got bogged down, keypress events in places like the address bar would get dropped on the floor rather than queueing up. (Or the findbar bug I reported months ago, which is still a problem, where, if the browser is bogged down, "<Ctrl+F>foobar" can result in something like "obarfo" in the search field because Firefox doesn't suppress delivery of keypress events to the search fields until after it's reset the cursor state, so you wind up with fo<reset cursor>obar.)

Anyway, as a Linux user, I can easily run a quick test with xev to demonstrate that the coordinates Firefox should be using are present in the XButtonReleasedEvent struct on X11:

ButtonRelease event, serial 37, synthetic NO, window 0xfc00001,
root 0x1dc, subw 0x0, time 1971670983, (167,63), root:(1116,543),
state 0x110, button 1, same_screen YES

-- /usr/bin/xev output resulting from releasing a click on the test window.

The struct in question is defined as follows:

typedef struct {
    int type;        /* ButtonPress or ButtonRelease */
    unsigned long serial;    /* # of last request processed by server */
    Bool send_event;    /* true if this came from a SendEvent request */
    Display *display;    /* Display the event was read from */
    Window window;        /* ``event'' window it is reported relative to */
    Window root;        /* root window that the event occurred on */
    Window subwindow;    /* child window */
    Time time;        /* milliseconds */
    int x, y;        /* pointer x, y coordinates in event window */
    int x_root, y_root;    /* coordinates relative to root */
    unsigned int state;    /* key or button mask */
    unsigned int button;    /* detail */
    Bool same_screen;    /* same screen flag */
} XButtonEvent;
typedef XButtonEvent XButtonPressedEvent;
typedef XButtonEvent XButtonReleasedEvent;

[...]The x_root and y_root members are set to the pointer's coordinates relative to the root window's origin at the time of the event.

[...]If the event window is on the same screen as the root window, the x and y members are set to the coordinates relative to the event window's origin. Otherwise, these members are set to zero.

-- https://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html#XButtonEvent

Oh, just to clarify, "If the event window is on the same screen as the root window" doesn't refer to physical monitors. You can hang multiple monitors off a single X11 Screen and that's how typical X11 desktops do it these days.

A desktop with multiple X11 Screens acts more like the Synergy software KVM, where each screen will have its own independent window manager and the mouse can travel between them, but application windows cannot without special support from the application for manually creating a new window, transferring the state over, and deleting the old one. It's a holdover from an era before Xinerama introduced the ability to merge multiple monitors into a single screen and is colloquially known as "Zaphod mode" after Zaphod Beeblebrox from the Hitchhiker's Guide to the Galaxy series.

In other words, not really something Firefox should have to worry about.

Problem still occurs in Firefox 71.0, which is the version currently shipping in Ubuntu.
Problem also occurs with the lightning calendar tabs in Thunderbird (version 68.2.2).

72, too

Still happen on FF 68.1.0esr

There's a workaround explained in a comment for bug 1610764, https://bugzilla.mozilla.org/show_bug.cgi?id=1610764#c1.

"Starting with Firefox 74, you can disable the feature altogether by entering about:config into the address bar and setting browser.tabs.allowTabDetach to false."

I think the words are too strong: On that other bug it says "Resolved" and here it says "workaround". I never wanted the tabs to never detach. I have been using a stupid addon that allows me to 1) lock tabs in place, 2) click the X button to disable the app and then tear off a tab when I want, and then 3) click the X to lock tabs again. It makes things FF at least usable. Someone above mentions the details of the bug, why it happens, and I assume a path to fixing it. It must be related to issues such as screen size, DPI, etc, so that not everybody sees it all the time, but it's clearly wrong. Tabs flying around the screen is pretty annoying, so I hope this doesn't get lost.

(In reply to timbo63 from comment #46)

It must be related to issues such as screen size, DPI, etc, so that not everybody sees it all the time

In my experience, it's actually related to how Firefox handles events while under heavy load. (A recurring flaw that's popped up in various places since at least Firefox 2, when Firefox on Linux would lose keypresses in the address bar if it was under heavy load.)

Specifically, the symptoms I get seem to indicate that it's distinguishing between clicks and drags by processing button release events against the pointer coordinates at the time the event is processed, rather than the "at the time the event was generayed" coordinates stored in the event itself.

Blocks: 1637238

Still happens few times a day on on FF 76.0.1

Tab tearing can now be disabled in about:config (At least on nightly).

Set browser.tabs.allowTabDetach to false.

"disable tab detach" does not fix "too sensitive".

I haven't tried nightly but, if we really can't have Firefox properly using the event coordinates from the window system-level press and release events rather than grabbing them fresh at whatever time it processes the event as it appears to do, my ideal solution would be for browser.tabs.allowTabDetach=false to allow dragging tabs between windows (with window creation accomplished via <kbd>Ctrl</kbd>+<kbd>N</kbd>) but interpret any "drag" that's not a successful drag to a pre-existing window as an over-sensitive click.

Ugh. Forgot to preview that before assuming it'd support GitHub-style use of <kbd> tags. Sorry about that.

What is the behavior that causes this? I see this frequently not knowing what I just did. It seems like moving my mouse across the desktop will sometimes cause this behavior.

Just moving the mouse "shortly" after you clicked on a tab is enough to trigger this bug, especially under high load conditions.

What happens is that firefox for some weird reason does not get the mouse position directly from the button-release event, but instead prefers to request it separately. Under high-load condition, this means that the mouse may have moved since button release, and firefox wrongly interprets that as a drag.

Solution seems to be simple: just get the coordinates from the event, but for some reason it's always the "easiest" bugs that take the longest time to fix :-(

Since there seems to be no way to vote up a comment, I'd like to add my voice to what Alain has just written. Why not just fix a simple bug so that an addon is not required to improve the user experience?

Adding support to what David Spector said. How much work went into creating an addon that snaps rogue tabs back to where they belong?!? Just change the mouse position to what it was supposed to be... (I appreciate the folks that were able to figure out the root cause of this!)

(In reply to Alain Knaff from comment #54)

Just moving the mouse "shortly" after you clicked on a tab is enough to trigger this bug, especially under high load conditions.
...
ahh.. that's exactly it! Thank you (needs some sort of direction & gesture logic)

(In reply to Claude Gohier from comment #45)

There's a workaround explained in a comment for bug 1610764, https://bugzilla.mozilla.org/show_bug.cgi?id=1610764#c1.

"Starting with Firefox 74, you can disable the feature altogether by entering about:config into the address bar and setting browser.tabs.allowTabDetach to false."

This setting is not working 100% correctly. It still displays the animation of the tab.

(In reply to Anjo from comment #58)

(In reply to Claude Gohier from comment #45)

There's a workaround explained in a comment for bug 1610764, https://bugzilla.mozilla.org/show_bug.cgi?id=1610764#c1.

"Starting with Firefox 74, you can disable the feature altogether by entering about:config into the address bar and setting browser.tabs.allowTabDetach to false."

This setting is not working 100% correctly. It still displays the animation of the tab.

It's working as intended. It only disables the "tear off" behaviour. You can still drag-and-drop reorder tabs within the same window or choose Move Tab > Move To New Window from the context menu and then drag tabs between two windows that already exist.

That means you still get the two animations (the Firefox-provided dragging within the same tab bar and the OS toolkit-provided drag-and-drop visualization for dragging outside the tab bar) because it can't tell whether the drag is valid until you've dragged a certain distance (within the tab bar) or released the button over a valid drag target (dragging tabs from one window to another).

I think several of us here don't want to disable all tear offs, we just want the tear off to work "normally" and not become hyper-sensitive. The addon allows me to click a button, tear off a tab, and then click the lock back on so that the rogue tear offs snap back. Inconvenient, but it's the best solution so far (vs. fixing it).

I recall that this was more of a problem on my home PC and work PC. I don't know if the screen resolution, monitor size, or something else can aggravate the situation, but suspect that there are some variables that make it more annoying under certain use cases and not equally annoying to all users. (it was suggested above that PC loading may play a part). Can't someone on the inside just implement the fix offered above, discontinue addons, and close this thread? Thanks.

Wow, such an old issue.
I need to admit that I've never encountered this (very annoying issue) in the last 15 years of only using firefox on various machines, until I started using ubuntu (20.04) both with gnome and xfce (I migrated to xfce only hoping that it is due to gnome) as window managers.
Note that I did use ubuntu in the past and can't recollect having this issue ever.

Can't believe that this is not considered a bug (as it obviously manifest only in some specific conditions). Maybe devs looking into this don't understand that when it manifests it is extremely obvious and annoying as not intended behaviour. Again, I never had this issue in +15 years of using FF and now I have it several times per day in the last 6 months or so.

I have an update for this bug. It happens to me in Firefox 78 BUT ONLY FOR ONE TAB: I have BBC iPlayer permanently open in one tab of the 4 FF windows I have. Usually I can just click the tab and it switches to it, but there are times when it will open in a new window instead. Yes, it's easy enough to drag back to the original window, but it's annoying all the same.

But why should it happen with only one particular tab?

(In reply to Claude Gohier from comment #45)

There's a workaround explained in a comment for bug 1610764, https://bugzilla.mozilla.org/show_bug.cgi?id=1610764#c1.

"Starting with Firefox 74, you can disable the feature altogether by entering about:config into the address bar and setting browser.tabs.allowTabDetach to false."

OMG! Thanks for that! This bug has been err.. bugging me for a year or more. I searched for an answer before and came across this page, and there was only something about an extension to prevent the action, but the extension was dead. Today I had three tabs detach on me and I searched again, came across this page again, and now there's a way to prevent it. Thank you.

Addon "Disable Tab Attach" version 0.0.5 works fine for me. But, yes, you can also turn it off. As shown in some comments above, fixing the bug would be simple, just detecting the mouse position at the correct time. But for some reason none of the current Firefox developers seem to have the time to do this. I would do it if the Firefox development were easy, but it is rather hard to learn, involving all sorts of historical complications.

I am using FF84 on Windows and have the same problem. I have six windows open normally, with each of them having about six tabs, if that helps.

I do not want a workaround like disabling the tab attach. I want it to be less sensitive to mouse moves.

This stupid bug has now spread to Thunderbird. Why is it so hard to fix? Why is Mozilla determined to destroy any goodwill with its users? Why treat us with such contempt?

Dear Seán, Mozilla has no intention of treating anyone with contempt or destroying goodwill. Mozilla is truly trying its best as an open software organization. The problem apparently is simply that the few Mozilla developers able to fix this problem are not unified, but split in their opinions: some feel that there is a bug (and the cause is a time delay in measuring the position of the mouse, as described in detail above), some feel that there is a bug but that it is not important to fix in spite of this problem report of long duration (there is so much that is more important to complete), some feel that it is not a bug at all because they believe the feature works great when they try it out, and some misinterpret the issues because this problem never affects them. These are all human beings with opinions, and in this case the opinions appear to cause the inaction that you see. This bug report is not the proper place for a deep discussion and coming to consensus on this issue. I'm not sure such a forum exists, in fact. Perhaps an ideal organization would not display such inaction, but Mozilla is not an ideal organization. It is, however, a very good organization, for it has produced one of the top browsers in usage, features, and stability.

It is important to note that not every one uses the same hardware. This issue is often visible on slow and/or very loaded machines, while it may not be noticeable on recent, fast machines. If someone says that there is no bug because everything works well on his machine, this is just silly.

Of course, a fix should not have drawbacks for users of fast machines. But in such a case, if a common fix is not possible for all users, a solution would be to add an option for the preferences.

Here, it seems that the issue is caused by the fact that Firefox (and now Thunderbird?) considers the position of the pointer when it notices the button release instead of the position of the pointer at the time the button was released (as reported by the system). This is broken logic, thus it should really be regarded as a bug.

I appreciate David Spector's portrayal of things within the Mozilla system. I come from a hardware background (chip design) and it took me a while to realize why my boss would prevent changes that weren't necessary. As I matured as an engineer, I came to realize that "neat" changes from engineers often had undesirable consequences that broke things and made our customers angry. I came to enforce the rule myself to not make changes that add risk. Not to make this a feature debate, but each version of Firefox usually has me scrambling to fix addons, completely redo my new "tabs on the bottom" ccs customizations, etc, when I didn't want anything to be different and only wanted bug fixes.

I continue to use the Disable Tear addon, clicking it off when I need to tear, and then clicking it back on (it's a simple X button on my tool bar and always visible). It's strange to require. It seems to me that Stephan Sokolow showed some understanding of the root cause of this being how the mouse clicks are being handled. If I understand him, this is a bug and it's visibility is likely related hardware speed, mouse settings, resolution, etc. One wonders why this wasn't an issue for so long and then became and issue that refuses to go away for many (and one presumes for quite a few more that don't create bugzilla accounts to report bugs).

Can't we just agree on how and when the tear is enacted? If a person is clicking while the mouse is slightly in motion (ie, not held perfectly still), then don't tear. Can someone define something we can test as to the click and then the release to see what's going on? Thanks, Tim

For my part, I set browser.tabs.allowTabDetach to false and it fixed the problem for me. If I need to detach a tab, I right click the tab and select Move Tab -> Move to New Window.

(In reply to timbo63 from comment #70)

Can't we just agree on how and when the tear is enacted? If a person is clicking while the mouse is slightly in motion (ie, not held perfectly still), then don't tear.

This would not fix the bug. The issue is that one can click on a tab (the mouse isn't even in motion), but one or two seconds later, Firefox notices that the button has been released. In the mean time, the mouse could have moved (after the button has been released... but Firefox doesn't know that).

Vincent, I have to disagree with you. You may be experiencing that particular issue, but myself and others ARE experiencing the problem of moving the mouse slightly and causing the tear action to execute when it is not desired. While holding the mouse button down.

Gary, I think that what you are seeing is a feature. Note that tab tearing does not occur until some distance. Perhaps the threshold is too low for you, Personally I wouldn't mind if it were increased (this could also help for the issue with slow machines). But perhaps other users would complain, in which case the only solution would be to introduce a configuration option for this threshold.

Yes, it is a feature, and usually works great. I would love to have the threshold be configurable.

See Also: → 1669662

this issue is just 9 years old, give it 10 more years till its autodeleted by a bot :D

the prominence of HiDPI screens grows and grows, pixels are smaller now
please triage this to a higher level, it affects the usability of firefox on a daily basis for all users with good monitors

Flags: needinfo?(dao+bmo)

Moving a tab to another window by dragging does not work in Wayland (Gnome). It only works from context menu. Do you know when it is going to be fixed?

I've tested in on Gnome OS with Gnome 41 Beta, running on Wayland. (Virtual machine on Boxes). Dragging a tab to another window works in this environment, so there is hope it will work when Gnome 41 comes to Manjaro.

Moving a tab to another window by dragging does work in KDE with Wayland, so not being able to do it in Wayland must by a bug in Gnome. Hopefully it's going to be fixed in Gnome 41.

I believe there is a simple analysis of what causes this bug earlier in these comments, and it is in Firefox code, not in Gnome or any other external product. Something about obtaining the cursor position using the wrong part of the event exception structure. Should be easy to fix, according to some of the comments above.

(In reply to David Spector from comment #79)

I believe there is a simple analysis of what causes this bug earlier in these comments, and it is in Firefox code, not in Gnome or any other external product. Something about obtaining the cursor position using the wrong part of the event exception structure. Should be easy to fix, according to some of the comments above.

It's not that Firefox is using the wrong part of the event struct. Judging by the symptoms, it appears to be ignoring the position given in the event and independently querying the pointer position when it comes time to process it later. (Sort of like a copyright troll sending a nastygram to the person using an IP address at the time they queried the BitTorrent tracker, rather than who was using the IP address at the time the announce was sent to the tracker.)

I could certainly see that causing problems in something like Wayland which intentionally hides information about the global desktop state from applications for improved security. Hell, it wouldn't surprise me if GNOME is, intentionally or not, treating the coordinates it fed to Firefox in the event structure as some kind of identifying/authenticating cookie for a potentially cross-application operation like DnD, which can't be re-created by separately re-querying them later.

[Firefox] appears to be ignoring the position given in the event and independently querying the pointer position when it comes time to process it
later

Yes, that is the analysis I mean. Since this bug has been open for 10 years, why not just do it correctly (save the position given in the event) and see if it fixes the bug? What is special about this bug that requires 10 years of discussion?

(In reply to David Spector from comment #81)

[Firefox] appears to be ignoring the position given in the event and independently
querying the pointer position when it comes time to process it later

Yes, that is the analysis I mean. Since this bug has been open for 10 years, why not just do it correctly (save the position given in the event) and see if it fixes the bug? What is special about this bug that requires 10 years of discussion?

There's been a fix to this ancient bug which is just AWFUL. I now cannot move a tab either to reposition it in the same window, or to a different window. I'd rather have the old bug back than not be able to move tabs at all.
(Firefox 78 ESR)

(In reply to Chris from comment #83)

There's been a fix to this ancient bug which is just AWFUL. I now cannot move a tab either to reposition it in the same window, or to a different window. I'd rather have the old bug back than not be able to move tabs at all.
(Firefox 78 ESR)

Can you confirm you're not experiencing bug 1491496 instead? (Attempting to drag a background tab fails when clicking on the tab where its close button will appear)

That can easily be mistaken for an inability to drag tabs if you've got enough of them to shrink them down to just icons.

"Can you confirm you're not experiencing bug 1491496 instead? (Attempting to drag a background tab fails when clicking on the tab where its close button will appear)"

Definitely not. It used to be easy - even accidentally - to tear a tab off to reposition it or drag it to another window. I've tried this too many times recently to be mistaken. SOMETIMES a tab will reposition but more often it won't. Getting it to another open window is quite impossible.

(In reply to Chris from comment #85)

"Can you confirm you're not experiencing bug 1491496 instead? (Attempting to drag a background tab fails when clicking on the tab where its close button will appear)"

Definitely not. It used to be easy - even accidentally - to tear a tab off to reposition it or drag it to another window. I've tried this too many times recently to be mistaken. SOMETIMES a tab will reposition but more often it won't. Getting it to another open window is quite impossible.

...and I'll assume it's not bug 1698037 (Drag-and-drop and context menus break after 49.7 days of system uptime on Linux) since you'd have noticed if your context menus were refusing to stay open for more than a split second.

I'm on 91.0.2 (64-bit) on X11 with browser.tabs.allowTabDetach=false and it works the same as it ever has for me, so my advice for a start would be:

  1. Test whether a fresh profile alters your symptoms (There's a font-related bug that's caused by my profile that I'm trying to find time to minimize)
  2. If not, grab a copy of 91.0.2 from getfirefox.com and see if it's an ESR-specific problem.
  3. If you're on Wayland, see if switching to X11 has an effect on it.

"...and I'll assume it's not bug 1698037 (Drag-and-drop and context menus break after 49.7 days of system uptime on Linux) since you'd have noticed if your context menus were refusing to stay open for more than a split second.

I'm on 91.0.2 (64-bit) on X11 with browser.tabs.allowTabDetach=false and it works the same as it ever has for me, so my advice for a start would be:

1. Test whether a fresh profile alters your symptoms (There's a font-related bug that's caused by my profile that I'm trying to find time to minimize)
  1. If not, grab a copy of 91.0.2 from getfirefox.com and see if it's an ESR-specific problem."

I'm on 10.9.5 on Mac and using FF 78 ESR .. which is the latest version I can use. I suspect the bug stems from the last ESR update which upgraded the widevine component to allow Netflix etc to stream.

Just to enlarge on the behaviour: I just tried to move a tab (this one) along in its window. At the second attempt, a miniature of the window with low opacity appeared below the tab and I could drag it to move. Then, I was able to move it back again. However when I tried the same thing on another tab, nothing I did could repeat the process - no matter how long I kept the mouse button pressed down, the miniature didn't appear and I couldn't drag to move the tab.

I've just changed browser.tabs.allowTabDetach to "true" - which has at least allowed me to drag the tab to a new window; from there I can drag to any position in another window. That means it's now a clumsy two-stage operation, but that's better than nothing. Wish I could still drag to reposition in the same window though.

I wish someone would explain why a 10-year-old bug, whose cause and fix are known, has not yet been fixed. Is it non-reproducible on, say, Windows?

Severity: normal → S3

This is still an issue, making the amount of pressure / time to detach a tab adjustable would resolve this.

(In reply to smj from comment #90)

This is still an issue, making the amount of pressure / time to detach a tab adjustable would resolve this.

That depends. I've managed to get Firefox pretty bogged down and janked up, so it'd have to be set pretty high to be a reliable fix for the "not properly interpreting input event metadata" side of this bug. Otherwise, my cursor could be half-way across the screen before it checks the current cursor position when it should be checking the field for position at time of event generation.

This is hardly a vital feature that people are crying out for. You could just dump it.

Really? Hey Seán, if you've got nothing positive to contribute, quit wasting time and space over here and add your thoughts elsewhere! (I can't stand these types of comments from somebody without any skin in the game coming by to add their thoughts!!!).

So we've been dealing with this bug for 11 years! Earlier in the thread, someone seemed to understand the nature of the bug (the handlers, when mouse clicks are counted and analyzed, etc). That's something that could/should be fixed. Other people have suggested various workarounds which might make things better. I use some add-on that locks that tabs from flying off, then enable the feature when I do want to move a tab, then instantly put the lock back on. Clearly, I expected this thing to be fixed like 10 years ago, but got used to doing some extra clicks. Realize many people don't go through the bugzilla process.

I welcome all comments for people that can either fix this or implement a simple change that makes firefox more useable. When the tabs go flying around the screen, it is not usable. If chrome had the addons that I use, I would have switched to that 10 years ago...

(In reply to timbo63 from comment #93)

I use some add-on that locks that tabs from flying off, then enable the feature when I do want to move a tab, then instantly put the lock back on.

Without an add-on, the workaround I use is to set in about:config browser.tabs.allowTabDetach to false.

Then, if I want to detach a tab, I right-click on the tab, and select Move Tab -> To New Window.

You need to log in before you can comment on or make changes to this bug.