525366 - Middle mouse click opens empty tabs when no message is selected

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[dreadnaut]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5pre) Gecko/20091028 Shredder/3.0pre

Clicking with the middle mouse button anywhere in the folder and message lists opens a new tab. This also happen when no folder or message is directly under the mouse pointer, and when no message is selected, opening an empty tab.

Tested this on the latest nightly, with an newly created profile.

Reproducible: Always

Steps to Reproduce:
1. Make sure no messages are selected (ctrl-space can be used to deselect the last selected message, if necessary)
2. Move the mouse pointer in an empty area of the message list, e.g. below the last item
3. Click using the middle mouse button

Actual Results:  

A new tab opens in the background, without any content. In general however, I find strange the fact that middle click affects the current selection, instead of the current mouse target, as it usually does on Firefox.

Expected Results:  

Middle-clicking in an empty area of the folder or message list should, in my opinion, deselect the current folder or message, and no other action should be performed.




*Side-bug, I might open a new report for this if it's better:  right-clicking in an empty area of the message list when no message is selected open what seems to be an empty, 4x4-pixel context menu.

Comment 1

[Mark Banner (:standard8)]

Agreed this is a bug, but I wouldn't block on getting the big improvements in tb3 out to users for this - especially as there are no long-lasting effects, just a blank tab.

Comment 2

[dreadnaut]

Maybe I misunderstood the concept of blocking and RC. I thought that this was the kind of polish bug that would be left for last, RC work, to ensure a consistent behaviour when the stable version is released.

Is that 3.1 work then? and 3.0 means shipping the big changes, although rough?

As it seem to pertain a single function (msgMail3PaneWindow.js:ChangeSelectionWithoutContentLoad), I might try and work on it myself this time, and post the code :)

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #2)
> Maybe I misunderstood the concept of blocking and RC. I thought that this was
> the kind of polish bug that would be left for last, RC work, to ensure a
> consistent behaviour when the stable version is released.

Typically yes, however we're now past the first RC and we are trying to ship 3.0 in a balanced way - as soon as possible, but not with critical bugs.

> Is that 3.1 work then? and 3.0 means shipping the big changes, although rough?

No. 3.0 is shipping polished big changes. There may be a few minor bugs like this one. If this one is fixed in a manner that means there isn't much risk associated with it, then we would consider taking it for a 3.0.x release.

> As it seem to pertain a single function
> (msgMail3PaneWindow.js:ChangeSelectionWithoutContentLoad), I might try and work
> on it myself this time, and post the code :)

Feel free to, that's why we're open source ;-) If you need help, just ask.

Comment 4

[dreadnaut]

Attachment: Possible fix for the empty tab issue

Comment 5

[dreadnaut]

Wrapping the body of OpenMessageInNewTab() with an if (... != null) seems to solve the issue of the empty tab.

I am not sure about the other problem --middle or right clicking in an empty area of the tree or folder panel does not clear the selection-- as this seems to be a common behaviour in Thunderbird.

It should be noted, however, that Windows and common Linux file managers do clear the selection, and user might expect this to happen in Thunderbird as well.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 415489 [details] [diff] [review]
Possible fix for the empty tab issue

Thank you for the patch!  Mozilla style is to return as soon as possible to avoid confusion about the control flow so I have inverted the conditional.

Pushed to trunk:
http://hg.mozilla.org/comm-central/rev/999fa67b8c49

I agree that our behavior when something is selected but you are clicking in whitespace does not seem correct, but that should be tracked on another bug.

Comment 7

[Mark Banner (:standard8)]

Comment on attachment 415489 [details] [diff] [review]
Possible fix for the empty tab issue

I think we should consider this for 3.0.4, putting on the list.

Comment 8

[Mark Banner (:standard8)]

Checked into 1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/9b23468853d6