Closed Bug 489729 Opened 15 years ago Closed 15 years ago

Clicking a tab once and then moving your mouse in a downward motion causes a new window to open.

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Version:
1.9.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2b1
Tracking Flags:
Tracking Status
blocking1.9.1 --- .4+
status1.9.1 --- .4-fixed

People

(Reporter: geeknik, Assigned: tnikkel)

References

(
URL
)

Details

(Keywords: common-issue+, regression)

Attachments

(1 file)

patch?
2.71 KB, patch
jimm
: review+
dveditz
: approval1.9.1.4+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre Firefox/3.0.8

I browse with a lot of tabs and I've noticed that if you click on a tab once and after you release the click and you are moving your mouse in a downward motion, it will catch the tab and open a new window. I believe that this behavior is a regression that's happened recently (last 2-3 weeks) and has been talked about on forums.mozillazine.org. 

Reproducible: Always

Steps to Reproduce:
See details.
Actual Results:  
New window opens after you click on a tab once and then move your mouse downwards.

Expected Results:  
Clicking once on a tab and then moving your mouse in a downward motion should definitely NOT open a new window.

Could be related to https://bugzilla.mozilla.org/show_bug.cgi?id=488984 or https://bugzilla.mozilla.org/show_bug.cgi?id=466379 or another possibly related bug.
Summary: Clicking a tab once and move your mouse in a downward motion causes a new window to open. → Clicking a tab once and then moving your mouse in a downward motion causes a new window to open.
Version: unspecified → 3.1 Branch
Keywords: regression
This sounds like a mouse gesture extension which you have installed? Mouse-downward is the standard "open new window" in probably all of them.
I actually have a distaste for mouse gestures and have zero mouse gesture extensions installed. I can also cause this behavior to happen in Safe Mode. It's like Fx is hanging on to the click event a bit too long as I'm moving the mouse around.
After many attempts I have been able reproduce this on a new 1.9.1 profile on XP, but only when the tabbar was full , indeed I couldn't replicate it with less than about 20 tabs open. Even with a large number of tabs I can't reproduce this every time however. So although present, and annoying when it happens, the behaviour is very intermittent for me.
I can reproduce.

1. open few very heavy pages
2.during loading these page, on the background tab,
3.mousedown > mousemove 1-2 pixel(with in the tab) > mouseup > mousemove to content area. (each action do quickly)

Actual Results:
Tab detached.
It would be interesting to see if this bug is still reproducible now bug 493978 is fixed. Bug 493978 disables tab detaching if you drop the tab in the first few pixels of the content area.
Luke, fixing Bug 493978 unfortunately does not fix the problem I reported here.
Not fixed yet.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090605 Minefield/3.6a1pre ID:20090605044547
Same here.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99

Besides why doesn't the mouse pointer change when the tab is dragging? It behaves correctly in 3.0.* version. Take a look at this screenshot:
http://img197.imageshack.us/img197/1262/dragicon.jpg
this bug is still here in 3.5RC3.
It's very very noisy, please fix it for the final release

Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1) Gecko/20090624 Firefox/3.5
Why is this still marked as unconfirmed? Numerous reports here and @ forums.mozillazine.org confirm this is a problem. It should be blocking the 3.5 release or fixed by Tuesday. This is going to be in the top 5 or top 10 complaints when 3.5 is released.
I would like to echo the comments from #11 .... it is hard to reproduce BUT, it DOES happen and is VERY irritating!  I've yet to hear an explanation of the usefulness of this feature.....there definitely needs to be an option to turn it OFF.
It's not fixed in 3.5 final release, very bad thing.
It happens many times.
It makes FF 3.5 frustrating.

Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1) Gecko/20090624 Firefox/3.5
You can turn off this "feature" by installing the following add-on: https://addons.mozilla.org/en-US/firefox/addon/12276
So far, I've been using 3.5 for a day. In that time, I've unintentionally torn off tabs at least a dozen times. I spent some time searching through about:config expecting to find an option to disable it.

I have now installed the add-on (comment #17) to disable this "feature" - making 3.5 far less frustrating to use.

Please, we need an option to turn off this annoyance. It shouldn't be necessary to install an add-on to remove functionality. Add-ons are to add functionality. There should at least be an about:config option to disable the behaviour.
I totally agree with you Paul! :)
Please All vote on this bug. Thank You!
voted!

The add-on is really useful, NOW I can use FF3.5
useful but absurd
how can this bug still be unconfirmed?
Where is the spirit of firefox in this big bug ?
Flags: blocking1.9.1.1?
This bug appears to be related to the ratio of computing resources consumed over total computing resources on your machine.  In other words, if you have a fast, modern computer, then it will take over 20 tabs open to reproduce this behavior, like in comment #3.  But on an older machine, like my Pentium III 1.0Ghz with 512MB of RAM, I can reproduce this with only about 4 light tabs open (Google Docs, GMail, banking site, banking site #2).  There should definitely be an option to turn this off without an add-on.
blocking1.9.1: --- → ?
Flags: blocking1.9.1.1?
It happens all the time with me (and it is really, really annoying).
I'm on an Athlon64 3200+ with 1,5GB mem. Far from new, but also not a Pentium III.
Like those before me, why is it still unconfirmed? And why should one have to install an add-on to fix a bug?
My experience does NOT follow the "logic" in Comment #23 .... I have fast, modern computers and rarely have more than 8 tabs open (certainly never 20) and it happens....have seen it happen with 4 or 5 open.....I've gone ahead and installed the Add-On to fix it ( because it is SO irritating )....but as mentioned above, WHY should an add-on be necessary (it has been a issue for a LONG time)??  I've yet to see ( or hear ) much usefulness in "tab tearing" to begin with.
I'm not sure it requires a downward motion after releasing the tab to move it to a new window.
Most problems got fixed in bug 465346 (bigger threshold), but it's still possible to accidentally detach the tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We need to really understand what's going on here: as summarized, this is a bug, since users should need to click and DRAG to detach a tab.

If it's the case that it's possible on some XP systems that a click is misinterpreted as a click-and-drag, this is a serious bug that needs investigation.

If it's the case that some people are just accidentally drag detaching, I'm less concerned.

Can we get someone with an XP system and the ability to profile to figure out what's going on here? I still can't reproduce this locally. :/

Once we have more information, please renominate.
blocking1.9.1: ? → -
Keywords: qawanted
This is not limited to XP and with many tabs.
I have experienced the bug many times on a modern Vista SP2 machine with as little as 3 tabs.
I am not sure if there was a tweak in 3.5.1 but i have experienced it far less often more recently as apposed to when 3.5 was released.
(In reply to comment #30)
> If it's the case that it's possible on some XP systems that a click is
> misinterpreted as a click-and-drag, this is a serious bug that needs
> investigation.

I first encountered it on Windows 7 RC.

> If it's the case that some people are just accidentally drag detaching, I'm
> less concerned.

If it's a "feature" that people are accidentally triggering, then it's a feature that needs to have an option to be disabled.
(In reply to comment #30)
> We need to really understand what's going on here: as summarized, this is a
> bug, since users should need to click and DRAG to detach a tab.
> 

Right, this is a bug because users don't hold their clicks when they drag their mouse to make this happen.

> If it's the case that it's possible on some XP systems that a click is
> misinterpreted as a click-and-drag, this is a serious bug that needs
> investigation.
> 

Right, it is a serious bug and should be investigated.  In the meantime, there should be an option to disable this "feature" without needing to install an add-on.

> If it's the case that some people are just accidentally drag detaching, I'm
> less concerned.
> 

Don't be.  The proper way to reproduce this is to click on a tab, release the click before moving the mouse, and then move the mouse.  On slower machines like mine, the tab being selected does not finish displaying by the time I move the mouse.  However, it should not matter since I have already released my click before I began moving the mouse.

> Can we get someone with an XP system and the ability to profile to figure out
> what's going on here? I still can't reproduce this locally. :/
> 
> Once we have more information, please renominate.

By the way, this "feature" is not unique to Firefox.  When I tried Google Chrome, I was constantly detaching tabs by accident in the same manner I did with the new version of Firefox.  This is why I quickly went back to Firefox.  At least with Firefox I could install an add-on to disable this.  It's not ideal, but still better than Google Chrome.
i hate this bug!!
I can reproduce 100% of the time with as few as two tabs open.  I'm using v3.5.1, windows XP on a modern machine.  The slightest downward movement of the mouse when clicking to view a different tab detaches the tab in a new window.  This bug essentially defeats the tabbed browsing feature that converted me to firefox years ago--very annoying.
This bug happens too often to me...
URL: http://groups.google.com/group/chromi...
Component: Tabbed Browser → Widget: Win32
Product: Firefox → Core
QA Contact: tabbed.browser → win32
Version: 3.5 Branch → 1.9.1 Branch
Depending on the timing, I sometimes can reproduce the bug.
I guess its because im using a touchpad (too slow?)
happens to me too , i dont tryed to repoduce , but surfing the web sometimes i get a old tab opened in new window ..
Attached patch patch? — — Splinter Review 
So this patch just changes the two instances of GetCursorPos in the drag code to GetMessagePos based on the link that Dão added (http://groups.google.com/group/chromium-dev/browse_thread/thread/7324c9f402b5295d). I tested it and it seems to fix the problem (can't be 100% certain due to lack of ability to reproduce on command).

There are a few more instances of GetCursorPos in the codebase in embedding and in a test. Somebody who is more familiar with that code might want to look into that.
Assignee: nobody → tnikkel
Attachment #393464 - Flags: review?(enndeakin)
Attachment #393464 - Flags: review?(enndeakin) → review?(jmathies)
Comment on attachment 393464 [details] [diff] [review]
patch?

Nice!
Attachment #393464 - Flags: review?(jmathies) → review+
Keywords: qawanted → checkin-needed
Whiteboard: [needs landing]
From the google groups thing this seems to be a known issue with this api...
blocking1.9.1: - → ?
status1.9.1: --- → ?
http://hg.mozilla.org/mozilla-central/rev/005a9a447d4a
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.2b1
Not blocking 1.9.1.x, but we'll consider a patch.
blocking1.9.1: ? → -
status1.9.1: ? → wanted
Comment on attachment 393464 [details] [diff] [review]
patch?

This should apply to 1.9.1.
Attachment #393464 - Flags: approval1.9.1.4?
blocking1.9.1: - → ?
(In reply to comment #45)
> Not blocking 1.9.1.x, but we'll consider a patch.

Sorry, I missed that comment. Why do you think this shouldn't block? Beltzner originally minused it because we didn't understand what was going on. Now we do.

It's a regression from 3.0 that makes using Firefox painfully annoying for some users, and I think we actually should have made sure to fix this before pushing major updates.
(In reply to comment #47)
> (In reply to comment #45)
> > Not blocking 1.9.1.x, but we'll consider a patch.
> 
> Sorry, I missed that comment. Why do you think this shouldn't block? Beltzner
> originally minused it because we didn't understand what was going on. Now we
> do.
> 
> It's a regression from 3.0 that makes using Firefox painfully annoying for some
> users, and I think we actually should have made sure to fix this before pushing
> major updates.

In addition this could lead to dataloss, happened to me once on a flash site. After the new window was loaded everything was gone.

These regressions are very bad, I have to convince freinds to turn on auto updates back because they complain about slower, unresponsive browser when they update to new version and these bugs are on top of that...
The patch extension worked for me. However, hopefully it will be fixed as a patch/extension should not be necessary. I have faith in FF guys. Just glad to be rid of that annoying new window that seemed to happen randomly.
We'll pick this up in 1.9.1.4.
blocking1.9.1: ? → .4+
Comment on attachment 393464 [details] [diff] [review]
patch?

Approved for 1.9.1.4, a=dveditz for release-drivers
Attachment #393464 - Flags: approval1.9.1.4? → approval1.9.1.4+
Keywords: checkin-needed
Whiteboard: needs 1.9.1 landing
What is the link to the Add-On called Bug 489729 ?  It is a fix to this.  I have it, but need the download link for a SUMO forum question.
Link is https://addons.mozilla.org/en-US/firefox/addon/12276
For nightlies you have to tweak compatibility check.
This problem sometimes still happens.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090831 Minefield/3.7a1pre ID:20090831044843
Keywords: common-issue? → common-issue+
(In reply to comment #60)
> This problem sometimes still happens.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090831
> Minefield/3.7a1pre ID:20090831044843

The gesture still exists as the shortcut to move a tab into a new windows : if you drag the tab on top of the current content, a new window will be opened. That's intentional.

This bug was about the accidental activation when you just wanted to click the tab.
> The gesture still exists as the shortcut to move a tab into a new windows : if
> you drag the tab on top of the current content, a new window will be opened.
> That's intentional.

Is it possible to provide an about:config option for that? Or undo?

I opened a bug specifically for that "intentional" behavior - but is was duped to this one.

I never even needed such functionality, but by accident it happens to me all the time.

Providing undo of some sort might also help. Biggest problem for me is to find the original place where from the tab was removed. I never needed such function - it only messes up my workplace when I trigger that by accident. And that happens quite often - about once per day.
(In reply to comment #61)
> (In reply to comment #60)
> > This problem sometimes still happens.
> > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090831
> > Minefield/3.7a1pre ID:20090831044843
> 
> The gesture still exists as the shortcut to move a tab into a new windows : if
> you drag the tab on top of the current content, a new window will be opened.
> That's intentional.
> 
> This bug was about the accidental activation when you just wanted to click the
> tab.
The tab is separated with high probability when I click a tab while moving a mouse from the top to the lower direction quickly. There is not the awareness that dragged a tab.
Is an automated test possible?
Flags: in-testsuite?
Is there any way we can control the mouse in automated tests so that it affects what win32 will report when we call GetCursorPos?
I can confirm this bug is still present.
Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 ID:20090729225027

If this really a feature, it should be made that it needs a sensible amount of dragging (i.e. 50 pixels or more) to trigger tab detach, not just 1-2 pixel
(In reply to comment #68)
> I can confirm this bug is still present.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.1.2) Gecko/20090729
> Firefox/3.5.2 ID:20090729225027

The patch is not in the version of Firefox listed here.
I'm using the latest version 3.5.3 and this bug is still present.
This bug will not be fixed until Firefox 3.5.4.
I can't reproduce this problem.

For those that can, please try the latest 1.9.1 nightly build from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/. This has the code that will be going into the 3.5.4 release and it should fix the problem. It would be nice to have some of the people that have been reliably experiencing this give the build a try.
(In reply to comment #75)
> I can't reproduce this problem.
> 
> For those that can, please try the latest 1.9.1 nightly build from
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/. This has the
> code that will be going into the 3.5.4 release and it should fix the problem.
> It would be nice to have some of the people that have been reliably
> experiencing this give the build a try.

I've been using the nightly build for 2 days with no problem. Should it happen again I'll write about it. Otherwise, goodbye and thanks for all the fish!
This happens to me all the time and it's become very frustrating. I'm not a computer expert and have no idea what to do with the 'build' linked above. I certainly refuse to install any add-ons to resolve this problem because it shouldn't be happening at all. Please fix this.
It IS already fixed, and will be in Firefox 3.5.4. That 'build' is not an add-on, but an early version of 3.5.4 for test purposes. Don't install it unless you're a tester.
How come the status for this bug it is "RESOLVED FIXED"?
I have the latest version 3.5.4 and this problem it's still present... There is something else i have to do, other than remove completely the older version before using this latest version?
You can still detach a tab by dragging it, for example by dragging the tab onto the content below. That is a feature (gesture) and will stay. You need it anyway if you work fullscreen, so that there is no desktop to drag the tab to (which is the normal gesture to trun a tab into a window), or other windows are not reachable (which is the normal gesture to move a tab to another window).

This bug was about the fact that it got often triggered by accident, for instance when you wanted to switch to a different tab, and you clicked on it with the mouse. In some cases, the mouse coordinates were misinterpreted, and it was considered a drag.
"In some cases, the mouse coordinates were misinterpreted, and
it was considered a drag."

I'm using more browsers, and i'm used to move the mouse very fast. This is a problem when i'm using mozilla firefox (3.5.4), because the pages are still opening in a new tab with no dragging - just by moving the mouse. If i move the mouse slowly there is no issue, but it is annoying...
There are reports that it still happens in some circumstances. We should track this in one of the newly filed bugs like bug 529518.
Hi,

I am using Firefox 4.0 and it still happens to me every now and then (about once a week) that firefox opens a new window against my will. THIS BUG IS NOT FIXED. If you really think some people need this tear down tab feature (what for?!), than please provide an option to disable it.

Thanks,
ajf
ajf, Install bug489729 (Disable detach and tear off tab) Firefox addon to solve the problem.
https://addons.mozilla.org/hu/firefox/addon/bug489729-disable-detach-and-t/
I found that out by now. I still think it shouldn't be necessary to install an addon to fix a bug.

Best,
ajf
Still occurring in the latest build of Nightly..
NOT FIXED. Still ocurring every now and then in 8.0.1 under Windows XP. :-( Very annoying.
It's fixed, I have just obeserved 1 or 2 times since this patch.
Slow computer, "heavy" finger on the mouse button, sudden downward movement, etc... various causes may imply this behaviour.
AMD X4 2.6GHz. Although not the cutting edge in terms of speed, far from a slow computer.

Even having the heaviest of the heavy fingers won't change the fact that the computer will just detect that the button is either pressed or not.

Also, as "sudden downward movement", I (and a lot of users, it seems) consider that gesture-related UI features should not react to sudden movements, especially when the results are so intrusive (as it is the case of detaching a tab and opening a new window). IMHO, there should be ZERO cases for this type of bug to be considered fixed. The UI should not respond when the user didn't meant it to. We can always blame the computer speed, low memory, disk swapping, video drivers, etc. but I always thought that this is below Mozilla standards.

Of course, it CAN BE a performance issue -- i.e. this may be a feature that works badly on slow computer. But if this is the case, then there MUST be a way to turn the feature off. C'mon, don't tell me that installing an addon named "bugXXXX" is a real solution, because it is not. I understand that it may be tricky to find exact timings on UI gesture-related code, but I find hard to believe that adding an "about:config" boolean to turn off the feature is that difficult.

Loic, I'm fairly experienced long time computer user and programmer, and I can assure you that my machine has no slow down, has no virus, no swapping, etc. And this problem is happening a lot here. Even on windows with only 3 to 4 tabs. And it's very annoying. NO OTHER gesture-related annoyance happens on the machine, neither in Firefox (e.g. moving tabs, moving current URL to favorites bars, etc.) nor other software.
Not fixed, happens even in Firefox 10.0.2.
The "disable detach tab" extension won't work at all. I'm using Tab Mix Plus and Tree Style Tab.
This is extremely annoying.
It's fixed, try in safe mode.
I tracked down the problem to an extension I was using: Live PageRank. Had it disabled and the apparently random detachment of tabs stopped to happen. No occurrence since then.

For those who do not know, the Live PageRank extension issue a request to Google servers to get the PageRank of the URL being viewed. So apparently, it's a timing issue (i.e. bug). From an end user perspective, apparently the browser register the mouse down event but suddenly give back control to the extension so that it can do its work. And since network requests are relatively slow, by the time the request ends your mouse pointer may have moved out of the tab, and when you release the mouse button outside of it... bang the UI understand that you really wanted to detach the tab, and it act accordingly.

One thing I noticed is that the queried URL (toolbarqueries.google.com) return DNS RRs with a very low TTL (300s). This will cause any caching name server to forget result each 5 minutes and force new DNS requests every 5 min. Is the browser perhaps hanging on DNS queries? This MAY explain why this problem was hard to reproduce by me and apparently occurred randomly, though in a frequency that fits well on a 5 minute time frame.

People experiencing this problem may try to temporary disable extensions that do background request, which may include additional toolbars and other plugins. If the problem go away, we may be more confident that it's a network-related timing issue.

This is a real issue, and it's not fixed. And I don't think that advising people to run their browsers in safe mode do any good to solve it, neither to FF in general. If you think that it's an extension issue, then fine, but it still a bug nonetheless, that deserve being handled as such -- unless, of course, the developers clearly state that extensions should not be doing this-and-that-way network requests.
There are multiple extensions which trigger this bug.  Since some of them are bug fixes themselves (like "Last tab close button" which as a side effect fixes the crash to desktop on ^W), marking this one fixed is not appropriate.

If there is a bug in those unrelated extensions, please point it out.
I have exactly this happening when I open Firefox 22.0 (I use the "continue with last session's tabs option") and log into the tab I use for admin'ing my router.  I click on the router admin login widget, which is equivalent to clicking on the tab, and then when I move the mouse down across the tab to move it away (no mouse buttons pressed when I do that!), it brings up a new window with just that tab.

I'm trying the "bug489729" extension now to see if I can disable this, it is pretty annoying.  I never want this behavior, so I don't mind disabling it at all.  If I'm the only person seeing this, I'd be really amazed.
re [comment 97]:
No, you are not the only one.  However in my case, I think this may be caused by TreeStyleTab extension that is declared incompatible with the extension to workaround this bug you mentioned (/me hopes Firefox will finally get natural vertical tabs any time soon).
(In reply to rvortman from comment #97)
> I have exactly this happening when I open Firefox 22.0 (I use the "continue
> with last session's tabs option") and log into the tab I use for admin'ing
> my router.  I click on the router admin login widget, which is equivalent to
> clicking on the tab, and then when I move the mouse down across the tab to
> move it away (no mouse buttons pressed when I do that!), it brings up a new
> window with just that tab.
> 
> I'm trying the "bug489729" extension now to see if I can disable this, it is
> pretty annoying.  I never want this behavior, so I don't mind disabling it
> at all.  If I'm the only person seeing this, I'd be really amazed.

You need to test with a cean profile before claiming it's a Firefox issue.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Sidenote: having more windows opened (deliberately or not as is this case)
will expose [bug 896253] with single HTTP auth dialog vs infinite load
at other windows.
I'd like to file a new bug, but what I've read here shows that any bug (even if not identical to the title of this bug) will get reassigned here.

I recently installed a high-res mouse.  It seems to always be rock solid, but I now have an issue where I get tabs detaching.  My assumption is that micromovements are detected beyond the threshold, and boom -- new tab.

I have zero issues with any other software, and even when drawing lines in GIMP and such I see no deviation to assume it is me that is at fault here.  That said...

Why on earth should I need to install something as insecure as an add-on, simply to disable this feature.  I found 'tabmix', which may be secure, but it also includes all sorts of other blather.  I found other add-ons, but I don't feel like code-auditing them, nor doing so on a regular basis as firefox-changes often require new versions of add-ons at a frequent basis.

My point is inherently this... I trust firefox's code, to a point of course, but add-ons have been shown to be very, very open to being sold to third parties.  To being more open to hacking, with smaller time devs having their machines audited, and no other dev team to act as a check-valve with strange commits.

I would suggest that there should be a policy shift, one where you guys ensure that EVERY FEATURE have a way to disable/enable via about::config.  That add-ons are NEVER an answer to an issue many users are having, if a simple about::config can resolve that issue.

I understand that large-scope GUI changes aren't going to necessarily be provided for users via about::config.  But, this isn't that.  This is a simple thing that could be provided via about::config, but instead you are forcing users to go to external, insecure, unsafe resources to get resolution.

Please, think on this.  I'm going to open another generic bug on this topic, hoping to get some traction on this simple idea.

Thanks
(In reply to Brad Barnett from comment #101)
> I'd like to file a new bug, but what I've read here shows that any bug (even
> if not identical to the title of this bug) will get reassigned here.
> 
> I recently installed a high-res mouse.  It seems to always be rock solid,
> but I now have an issue where I get tabs detaching.  My assumption is that
> micromovements are detected beyond the threshold, and boom -- new tab.
 
New mouse seems to have triggered this for me too. Not really resolved. This should require a lot more to trigger - a *slow* click and drag and a right-click menu option. I do use this feature occasionally but I don’t find drag down to be intuitive at all. The first place I’d look is the right-click menu.
BTW, "Component: Widget: Win32" is incorrect, it happens for me on Linux too.  And it's got far worse than before: it happens all the time when reordering tabs (horizontal drag), and often even during regular clicks.  I can't tell when it became worse, though -- I use https://addons.mozilla.org/en-US/firefox/addon/bug489729-disable-detach-and-t/ normally which fixes the issue.
This also happens to me on Linux
I'm being affected by this on Ubuntu 16.04 with KDE 5.7 too.
This stopped happening after a few releases since my 2012 post.

However, it annoyingly started to happen again (ESR 45.3.0 -- standard Debian Jessie package).

Now I went back to this bug just to see many recent posts popping up at the same time.

Sorry, but this is a clear indication that we have a real issue here.

All that said, I am not sure if having hidden options to disable any new feature is the way to go.

But surely, having a way to disable an ANNOYING problem that no one is able to identify/fix for almost half a decade seems the more prudent thing to do.

(It's sad to see this issue marked as "RESOLVED/FIXED" when it's not -- and probably no dev will care to look at it.)
Yes, it _is_ annoying, and RESOLVED/FIXED is wrong.  But those of us non-devs can simply install the bugfix extension and go on our way.
How can I disable tab detach/tearing? The add-on recommended here has been removed for some reason. I wish there were a preference for this.
I've found the author of the removed extension, there is the needed code on GitHub.

Now you have to do this to disable tab detach/tearing:

Install userChromeJS extension from here:
http://userchromejs.mozdev.org/

Then in your profile folder (you can find it in about:profiles) will appear "chrome" folder and inside it "userChrome.js" file, replace it with the file from here:
https://raw.githubusercontent.com/alice0775/userChrome.js/master/patchForBug487263_489729.uc.js

Restart your browser afterwards.
Mosila Firefox for Ubuntu 55.0.2

Issue still reproduce stable. 
Patch patchForBug487263_489729.uc.js don't help.

Is it possible to disable this feature "Open exist tab in new window"?
Flags: needinfo?(tnikkel)
I don't work on front end code.
Flags: needinfo?(tnikkel)
Given that this is *not* fixed and it's no longer possible to solve it using a WebExtension without also killing off the Move to New Window context menu entry which I DO use, can we get this bug reopened or should I re-file it as a new bug?

(The only time I *ever* "tear off" a tab is when I click a tab, the browser janks at just the wrong moment and interprets it as a tear-off operation, and then I curse and drag it back into place.)
Aye, seconded: this happens way too often during normal browsing, while trying on click on a tab for regular purposes, even with a regular mouse.  Then, try to move a tab to reorder it while using a touchscreen...

The sensitivity is way off.  If it'd be tricky to fix it, what about just adding an option to disable "drag to tear off" completely?  Despite using multiple monitors, I can count times I did so for the browser _intentionally_ on the fingers of one hand -- every time using the nice right-click menu.  Rarely used options shouldn't interfere with normal use.
Beyond that, this isn't the only place, over the years, where I've seen a bug that boils down to Firefox processing events based on the time they were handled rather than when they were emitted.

(It's not even the only bug I've reported that comes down to Firefox's tab bar munging together attributes which should be disjoint when processing events in the tab bar.)

Xlib's XButtonEvent contains x,  y, x_root, and y_root members ( https://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html ) and Firefox is the only application I've ever seen this problem show up in.

Those docs even explicitly say "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." (emphasis mine) so, unless X.org is horrendously broken in a way which affects no application other than Firefox, fixing this is a simple matter of comparing the x_root and y_root members of the press and release events, rather than the pointer's coordinates at the moment the events are processed.
I accidently updated FF version 50+ (don't remember which one exactly) and many extensions were gone. I had to install 52 then 56 to make them work. This bug was not present but now it is. Why this came back to me? Do you know how to restore previous functionality?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: