Open Bug 935920 Opened 11 years ago Updated 2 months ago

Mouse middle/scrollwheel button click should honor Option to open in new Window

Categories

(Thunderbird :: Message Reader UI, defect)

24 Branch
x86
All
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: tanstaafl, Unassigned, NeedInfo)

Details

Attachments

(1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

Set Tools > Options > Advanced > Reading & Display > Open messages in

to 'A new message window'

But, when a user *accidentally* middle-clicks a message (or folder) when scrolling the message or folder list panes it opens in a new tab, and they end up with many - in fact it is not uncommon to find people with dozens, or even a hundred or more - open tabs that they had no intention of opening, don't want open, and often don't even notice.

This feature should honor the Option deliberately chosen to open in new Window.

I searched and asked everywhere, unable to even find a hidden pref to change or just disable (so middle-mouse-click does nothing) this behavior.


Actual results:

This has been driving me crazy for well over a year...

We have lots of users who are constantly winding up with many, sometimes dozens, and once or twice probably a hundred or more messages and folders opened in new tabs, and neither they nor I knew how this was happening. They do not want these opened in new tabs (and neither do I).

I *finally* figured out that they are accidentally middle-clicking when they are scrolling either the message or folder list pane, and middle-clicking on a message or a folder causes it to open in a new tab.


Expected results:

Since we have set the option 'Open New Messages in a New Window', this middle-click behavior should honor that setting and open these in new windows.

I would also love to learn of an about:config pref to just disable it completely (so middle-clicking does nothing at all).
I think this bug is wrongly categorized. It is about what Thunderbird does depending on a setting and not about the setting itself.
OS: Windows XP → All
No, it isn't...

The setting is set to one thing. Thunderbird does another. In other words, it is NOT doing what the setting says to do.
So Thunderbird is not respecting the setting. It is not the fault of the preference itself.
Component: Preferences → Message Reader UI
We could probably update the string in Preferences to be clearer, like "When double-clicking, open messages in: ...". The wording in many of the Prefs panes could stand to be improved, in fact.

As for the issue itself, this sounds like a hardware problem. If your users' mice make it easy to misclick, then they are using broken mice. While sacrifices must, of course, be made when purchasing in bulk, I don't think it's the place of a piece of software to work around poorly-designed input devices.
(In reply to Javi Rueda from comment #3)
> So Thunderbird is not respecting the setting.

Which is, in fact, the actual TITLE of this bug is it not?

> It is not the fault of the preference itself.

Ummm... I didn't say 'it was the fault of the setting', so I am really not understanding your point. It is as if you are just trying to pick a fight here.

The main problem here in my opinion is that this behavior is HARD-CODED. It should not be. I should be able to disable or otherwise change what happens when a message is middle-clicked.

2. (In reply to Jim Porter (:squib) from comment #4)
> We could probably update the string in Preferences to be clearer, like "When
> double-clicking, open messages in: ...". The wording in many of the Prefs
> panes could stand to be improved, in fact.

No, what 'we could do' is actually provide a way to change this behavior.

> As for the issue itself, this sounds like a hardware problem. If your users'
> mice make it easy to misclick, then they are using broken mice. While
> sacrifices must, of course, be made when purchasing in bulk, I don't think
> it's the place of a piece of software to work around poorly-designed input
> devices.

<sigh> It is not a hardware problem. It happens to me too, and over 30 of our users, all with different mice, some even expensive ones they bought  themselves.

Please stop trying to change the subject of this bug.

This behavior should not be hard coded in Thunderbird. There should be a way to define/modify what happens when a message is middle-clicked, and it should even be able to be disabled in my opinion.
I'm not clear on why you think that modifying this pref to affect middle-clicks would help. Wouldn't the user just end up with a bunch of new windows instead of new tabs? How does that prevent the problem?
Simple - they either don't even notice the new tabs being opened (most common), or they just ignore them.

I have seen users with hundreds of these, and when I ask about it, they just say something like 'oh, yeah, I remember seeing that and meant to ask you about it...'...

If they opened in new windows, they wouldn't be able to just ignore them.
New information... this is definitely a bug.

I just learned of 4 preferences that directly affect middleclicking - not sure how I missed them when researchingb this before (maybe they are new?)...

middlemouse.contentLoadURL
middlemouse.openNewWindow
middlemouse.paste
middlemouse.scrollbarPosition

The pertinent one would seem to be middlemouse.openNewWindow, which, on every system I've checked is set to true - and which appears to be the default.

so, this is obviously a bug, because the exact setting affecting this behavior is not being honored.

Would appreciate someone 'confirming' this as a bug.
(In reply to Jim Porter (:squib) from comment #6)
> I'm not clear on why you think that modifying this pref to affect
> middle-clicks would help. Wouldn't the user just end up with a bunch of new
> windows instead of new tabs? How does that prevent the problem?

Oh - and the problem is not that middle-click does 'something', the problem is that it doesn't do what it is being told to do.
(In reply to Charles from comment #8)
> New information... this is definitely a bug.
> 
> I just learned of 4 preferences that directly affect middleclicking - not
> sure how I missed them when researchingb this before (maybe they are new?)...
> 
> middlemouse.contentLoadURL
> middlemouse.openNewWindow
> middlemouse.paste
> middlemouse.scrollbarPosition
> 
> The pertinent one would seem to be middlemouse.openNewWindow, which, on
> every system I've checked is set to true - and which appears to be the
> default.
> 
> so, this is obviously a bug, because the exact setting affecting this
> behavior is not being honored.
> 
> Would appreciate someone 'confirming' this as a bug.

Those are for the browser component: http://mxr.mozilla.org/comm-central/search?string=middlemouse.contentLoadURL
I confirm that this is a bug for Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0.

Since I find tabs to be of zero value in tb, I would like to simply disable them.  There is no way to do that for middle click.

Toggling the config setting middlemouse.openNewWindow has no effect.

The open in new window option affects double-click, but not middle-click.  Um, if you are opening a new tab, then it should open where that option is set, to regardless of how you open it.

At the very least, I should be able to just plain disable the middle click frevvin's sake!  4 year old bug, and if the code is remotely reasonable, it should be trivial to add a config option.

Also, this is not a hardware problem  (blaming the victim?).  If anything, it is a wetware problem -- sometimes perhaps the animal presses too hard trying to scroll.

What's more, there may be other issues that cause spurious tabs, e.g. middle click when animal misjudged which window had mouse focus, or OS misdirecting clicks depending on timing of window restore or other timing issues.

I agree that at least if middle-mouse opened a new window, one would notice that right away, rather than later notice umpteen tabs open.

Maybe the day will dawn in some utopian future where tb and mozilla can achieve what emacs achieved, er, like 30 years ago:  a way to easily customize any keystroke, combination of keystrokes, and mouse press/release, with negligible effect on performance.

For those others who are annoyed by this bug, try setting mail.tabs.drawInTitlebar to false.  In that case, if only a single tab it is hidden, so opening a new tab causes a jump in the menu bar that might be noticed (if you have a menu bar).
Correction:  it's the "mail toolbar" that jumps.
Severity: normal → S3

Does this reproduce when using version 115?

Flags: needinfo?(tanstaafl)
Flags: needinfo?(foo459)
Attachment #9384441 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: