Open Bug 1336959 Opened 4 years ago Updated 11 months ago

Allow grabbing blank space on the Menu Bar to move the window

Categories

(Thunderbird :: Toolbars and Tabs, defect)

45 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: tanstaafl, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Tried to move the window by click+hold+dragging a blank space on the Menu Toolbar.

This works fine in Firefox...


Actual results:

... but not in Thunderbird


Expected results:

I should be able to drag/move the window around by click+hold_dragging a blank space on  the Menu Toolbar.
The ability to have both mail.tabs.autoHide AND mail.tabs.drawInTitlebar;true be true while the main window is not maximized was removed some time ago, because of this bug.
Which platform are you on? We have problem on Mac 10.12 (Sierra) at the moment.
Oops, sorry, just fixed that...

I'm on Windows 7 x64...
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
(In reply to Charles from comment #1)
> The ability to have both mail.tabs.autoHide AND
> mail.tabs.drawInTitlebar;true be true while the main window is not maximized
> was removed some time ago, because of this bug.

That you write this, do you have a special setting (extension, userChrome.css)? Can you please add a screenshot to show where the menubar is placed?
No special setting or userChrome styles. Just the Menu Toolbar.

The Menu Toolbar is in its normal place.

With Firefox, if I add a blank space to the Menu Toolbar, I can click+hold+drag the window around by clicking on the blank space in the Menu Toolbar.

You can't do this in Thunderbird.

This is a known issue, because, as I said in Comment 1, this was the very reason that the devs a few versions back disabled the ability to have both mail.tabs.autoHide AND mail.tabs.drawInTitlebar set to true (and work as expected).

See bug 779714 and bug 1273199 for details...
Blocks: 1273199
No special setting or userChrome styles. Just the Menu Toolbar.

The Menu Toolbar is in its normal place.

With Firefox, if I add a blank space to the Menu Toolbar, I can click+hold+drag the window around by clicking on the blank space in the Menu Toolbar.

You can't do this in Thunderbird.

This is a known issue, because, as I said in Comment 1, this was the very reason that the devs a few versions back disabled the ability to have both mail.tabs.autoHide AND mail.tabs.drawInTitlebar set to true (and work as expected).

See bug 779714 and bug 1273199 for details...
Under Win 7 on FX the menubar is above the tabs, on TB below (except in Classic). It makes no sense to make the window with the menubar in this position draggable. Then also the main toolbar should be draggable which is also not the case on FX.

I close this bug as invalid.
When you have a better reason why the menubar has to be draggable when it's below the tabs, the feel free to reopen the bug.

If you want to ask why the menubar is below the tabs, this is because a lot of people reported it was almost unreadable in the Glass area, also when it was the same as FX.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Reopening... I guess I wasn't explicit enough.

I used to have Thunderbird configured so that both mail.tabs.autoHide AND mail.tabs.drawInTitlebar were set to true.

I normally only have one tab open, and so with the above two options set, there was no Tab Bar because it was automatically hidden when only one tab was 'open', and the Menu Toolbar (on which I put all other buttons after slimming the menus down to just one with TinyMenu Addon) was drawn in the Titlebar, thereby maximizing my screen real estate.

Because the devs 'fixed' the bug of 'not being able to drag the window by the Menu Toolbar when the tab bar was hidden' by disallowing both of these options to be set true at the same time, even manually, I lost the ability to maximize my screen real estate.

I would like this capability back.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
You need to log in before you can comment on or make changes to this bug.