1406751 - [Linux, maybe wm-dependent] Single-clicking on the space between the urlbar and page content maximizes the window

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[wavexx]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20100101

Steps to reproduce:

Firefox 57.0 b6 just installed on Linux, default theme with default density.

Click on the space between the urlbar and the web page (I have roughly ~10 pixels available). The window is pseudo-maximized.

The same happens in the space between the urlbar and header bar and other empty spaces.


Actual results:

Click on the space between the urlbar and the web page (I have roughly ~10 pixels available). The window is pseudo-maximized.


Expected results:

Nothing. This space shouldn't trigger window maximization as it can be hit by mistake while trying to hit the url bar.

Likewise, hitting the empty space in the tabbar shouldn't trigger this kind of broken maximization. Clicking on the same space doesn't restore the original state. How am I supposed to exit this mode?

Comment 1

[Paul Graphonium]

[bugday-20171009]

Windows 7x64, Firefox 58. Bug is unconfirmed.

Comment 2

[Valentina Claudia Ona]

I verify this issue and is also reproducible on Windows 7 x32 and x64 using Firefox beta 57.0b7 and Nightly 58.0a1.

Build ID 20171009192146 
Mozilla/5.0 (Windows NT 6.1; rv:57.0) Gecko/20100101 Firefox/57.0

Comment 3

[:Gijs (he/him)]

Is this a regression from bug 1387415, maybe?

Comment 4

[:Gijs (he/him)]

(In reply to Valentina Claudia Ona from comment #2)
> I verify this issue and is also reproducible on Windows 7 x32 and x64 using
> Firefox beta 57.0b7 and Nightly 58.0a1.

Uh, with a single click? That would seem surprising, and I can't reproduce that. Only double clicks do anything.

Comment 5

[Valentina Claudia Ona]

Only if you double-click in that space.

Comment 6

[wavexx]

I just need a single click in both areas (note that the area extends also in the empty spaces between the toolbar buttons).

Comment 7

[Valentina Claudia Ona]

Attachment: ice_video_20171012-093651.webm

I can confirm this issue and it's also reproducible on multiple machines with double click
please see the attachment

Comment 8

[Dão Gottwald [:dao]]

This bug is about single click, as wavexx confirmed in comment 6.

Comment 9

[Valentina Claudia Ona]

I can't reproduce this issue with one click.

Comment 10

[Paul Graphonium]

Attachment: Between URLbar and header, ~10 pixels

Windows 7x64, FF 58x64

Comment 11

[Paul Graphonium]

We need a Linux system, because it maybe feature of OS and all attempt to reproduce are incorrect.

Comment 12

[Valentina Claudia Ona]

I verified this issue using Nightly 58.0a1 on Ubuntu 16.04 x64 and I can't reproduce this issue.

Comment 13

[Jim Mathies [:jimm]]

Hey Justin, can you set an appropriate priority here and figure out if we should track for 57?

summary: a single click in some areas of chrome triggers window resize on Linux.

Comment 14

[Dão Gottwald [:dao]]

We still need more information on under what conditions this happens, e.g. what Linux distribution and version.

WindowDraggingUtils.jsm calls window.beginWindowMove on mousedown which then calls gdk_window_begin_move_drag via nsIWidget::BeginMoveDrag. If this is somehow not working correctly, I think that ought to be a Widget: Gtk bug if it's a Firefox bug at all.

Comment 15

[wavexx]

This is happening on Linux, FF 57b6, with Debian unstable, using GTK 3.22.22 or 3.22.24.
The window manager is spectrwm, but I could reproduce it with awesomewm and openbox as well.
I'm not using a specific desktop system (no Gnome, no KDE).

However, FF56 with the same GTK version doesn't have the same problem, so I wouldn't put GTK as a suspect here, unless dragging by the tab-bar was introduced in FF57. By extension though, it looks like that dragging the window would work also between the addon buttons in the toolbar, which I would _also_ consider as a bug.

I have to be honest, I reverted to FF56 after a few weeks.
I've been accustomed to too many extensions that have no equivalent replacement yet.
This could change in the future, but for now I'm done with 57.

Comment 16

[Leimi]

Hi,

I encounter this exact problem using Firefox developer edition 57b14 on Arch Linux through the aur package https://aur.archlinux.org/packages/firefox-developer-fr/. I use awesomewm v3 as a window manager.

There is no bug using Firefox 56 (via https://www.archlinux.org/packages/extra/x86_64/firefox/) on the same machine.

Comment 17

[wavexx]

Verified this again on Linux 57 (final) on Debian unstable using many tiling window managers.

By inspecting with xev, it seems that simply *clicking* on the tab bar causes FF to sent a window-move event to the WM (even though the moved distance is 0 pixels).

This causes any tiling window manager to detach the window from the tiling.

This shouldn't happen. As for any drag operation, it shouldn't happen unless there's a minimal amount of motion involved.

The fact that the active area sits along under the entire urlbar is aggravating. A click just under the hamburger menu will also trigger this issue.

Comment 18

[Dão Gottwald [:dao]]

Can you reproduce with your add-ons disabled? See also bug 1419092 comment 5.

Comment 19

[wavexx]

Yes, just tried with a new profile.

Comment 20

[Len Trigg]

On Ubuntu 16.04 using WindowMaker as the window manager I get different problems depending which version of Firefox I'm using:


Firefox 57.0.1: 
1) Double click in either of the spaces beside the URL bar
* -> Instant Crash! (even in safe mode)
----------------
**
Gdk:ERROR:/build/gtk+3.0-2Ut_nl/gtk+3.0-3.18.9/./gdk/x11/gdkwindow-x11.c:5129:create_moveresize_window: assertion failed: (mv_resize->moveresize_emulation_window == NULL)
Redirecting call to abort() to mozalloc_abort

ExceptionHandler::GenerateDump cloned child 11361
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
------------------

Firefox Developer Edition 58.0b6: 
1) Minimize firefox window
2) Un-minimize firefox window
3) Single click in either of the spaces beside the URL bar
* -> Firefox window maximises!

Step 1 and 2 can be replaced by other window manager operations (e.g. Shade/Unshade (reduces window to just the title bar); Maximize/Unmaximize, etc)

Comment 21

[Karl Tomlinson (:karlt)]

Comment 20 is bug 1186967

Comment 22

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 23

[wavexx]

I can reproduce this also with FF58b14.

Short summary: Single-click on an empty space in the tab bar triggers a window-move event of 0 pixels. The same happens in several other (normally non-reactive) areas, such as the empty spaces between addon buttons next to the url bar, or the space between the urlbar and the tab-bar (a few pixels).

A missed click by a few pixels will cause FF to maxize in any tiling window manager.
The regression started in FF57.

Comment 24

[wavexx]

Other infos:

- GTK is 3.22.26, but likely not the cause (as written before, the regression was introduced in FF57 with GTK staying the same)
- For clarity: dragging and double-clicking in the empty space of tab-bar causes the same effects:
  * drags of a small-enough distance are processed as a click
  * drags of a large distance cause a window move, which inherently untile a window in a tiled window manager: I do not consider this a bug. 
  * double-click is buggy: a window-move event of a 0 pixels is caused at the end of the first mouse-release event (even before the second click). Double-click processing is obviously broken as well.

Comment 25

[Dão Gottwald [:dao]]

I expect bug 1455235 fixed this.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Not sure if we're going to want to take this as a late uplift for Beta, but I could see this being something we'd want fixed in ESR60 still.

Comment 27

[Rares Doghi, Desktop QA]

Hello, I tried reproducing this issue on Ubuntu 17.04 , 16.04 using Firefox builds 57.0b6 , 57.0b9 without any success , it would be a great help if you could recheck this issue on your Operating System using one of our latest builds you can find here: https://nightly.mozilla.org/ , and please let us know if the issue still occurs on your end. Thanks

Comment 28

[wavexx]

I verified on 59.0.2.

Comment 29

[Rares Doghi, Desktop QA]

Hi Wavexx , Sorry to keep bugging you with this issue, but it is still unclear for me if it reproduces or not using 59.0.2 build? Also, could you please try to verify this issue on the latest nightly build (you can find here: https://nightly.mozilla.org/), as from bug's comments it seems that this was fixed only on Nightly 61.

Comment 30

[wavexx]

Yes, it still reproduces on 59.0.2.

I tried nightly. It's better: nothing happens with a simple click, which is some progress.

But if I click and drag on the empty space in the toolbar (between the home button and the urlbar to be clear), the same problem appears again.

Are you supposed to be able to drag firefox around in that spot?

Comment 31

[Rares Doghi, Desktop QA]

Hi Wavexx, Thank you for your response, and to answer your question: Yes that is intended since version 57(Photon) i believe, i'm happy to hear that the above mentioned issue no longer reproduces on the latest nightly build.

I also tried reproducing the issue on Ubuntu 16.04 but without any success.

I will mark it Confirmed as Fixed based on comment 27 and comment 30.

Comment 32

[wavexx]

Then if that's intended, you should add a minimum drag distance.

It seems that a single 1px distance will trigger the drag, which is clearly not enough as it might still trigger the underlying issue if one has intended to click, but resulted in a drag instead.

Comment 33

[Rares Doghi, Desktop QA]

Hi Wavexx, the Space between the Home button and the address bar is called a "flexible space" and that can be removed from the Customize options, your idea for the minimum drag distance is great and you should add a separate issue to Bugzilla as an "Enhancement" and our Dev team will get to it when possible.

Comment 34

[wavexx]

Yes, but that space is not the only space where dragging works. The flexible space is just a coincidence.
Dragging also appears to work if you click *between the space of two buttons* in the toolbar.

I mean, does *that* make sense to you?

I'm sorry for being harsh here but... minimum drag distance is a basic UI concept that shouldn't require explaining.

Comment 35

[Rares Doghi, Desktop QA]

It does not :) , but this should be treated as a separate issue since the defect here was the Window resizing with a single click, you should definitely log a different issue for the minimum dragging distance area from a "Click" to be wider than 5 or 10px before resizing the entire browser window.