1415367 - Context menu appears under mouse cursor with IceWM

Status: UNCONFIRMED

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

Description

[Marcel]

Attachment: Screenshot showing context menu and mouse cursor position

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171106194249

Steps to reproduce:

1. Install Firefox 57rc1 and GTK 3.22.25 with default Adwaita theme under Arch Linux 64-bits.
2. Click the right mouse button somewhere in the middle of a (large) browser window with a page open.


Actual results:

The context menu appears under the mouse cursor (see screenshot), with the first item (usually the back button) or the divider bar (in text fields) being chosen when the right mouse button is lifted, resulting in firing a 'back' event or immediately closing the context menu again, respectively.

Side cases:
1) In case the cursor is too far to the bottom of the screen the context menu opens with its bottom about 20 pixels above the cursor, the x-coordinate is not changed.
2) In case the cursor is too far to the right of the screen the context menu appears even more under the cursor, the y-coordinate is unaffected, unless 1) occurs, too.


Expected results:

The top-left of the context menu should be positioned just below and to the right of the mouse cursor, provided that there's enough room. In case of side case 2) (see 'What happened?') the right side of the menu should appear a few pixels to the left of the cursor.

Note: when right-clicking on tabs, the address bar, bookmark bar items, or anywhere else on UI (non-page) elements, the behaviour is as expected: the top-left corner of the context menu appears slightly below and to the right of the mouse cursor.

This might be a GTK issue, as suggested in #841673 (which is very old), but in my case this behaviour appears everywhere within the page. Also note that Thunderbird 52.4.0 using the same version of GTK3 doesn't exhibit this issue; neither does Firefox 56. Adjusting layout.css.devPixelsPerPx, like discussed in #1326178, doesn't change anything about this behaviour.

Comment 1

[:Gijs (he/him)]

Karl, given that this doesn't happen to everyone using Firefox on Linux, I assume this is an artifact of theming and/or our GTK widget layer. Any ideas on what might have changed between 56 and 57 that would explain this?

Reporter: if you're able to run mozregression ( https://mozilla.github.io/mozregression/ ) then please use that to narrow down when this regressed.

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs (slow, PTO recovery mode) from comment #1)
> Reporter: if you're able to run mozregression (
> https://mozilla.github.io/mozregression/ ) then please use that to narrow
> down when this regressed.

+needinfo :-)

Comment 3

[Karl Tomlinson (:karlt)]

The size of the offset might be the window decoration size.  (In side case 2, the context menu is intended to be below the pointer, but not to the left.)
Given this is happening in content, but not chrome, it sounds similar to bug 1400238.  Perhaps it is the same issue, even though the offset was reversed in that report.  That is fixed in 58, so it would be helpful to test to see whether this is also fixed.  If testing Nightly, then use a separate profile.  58 will be beta in a few days, and so it may be easier to wait for that.

The regression from 56 to 57 might be that e10s is forced on in 57 by disabling incompatible add-ons.
I guess it is possible to force disable e10s in 57 to verify, but I don't know exactly how.
Perhaps something related to browser.tabs.remote.autostart.2.

Comment 4

[Marcel]

(In reply to Karl Tomlinson (:karlt) from comment #3)
> The size of the offset might be the window decoration size.  (In side case
> 2, the context menu is intended to be below the pointer, but not to the
> left.)

You hit the nail! That's also why other Arch Linux users didn't experience this bug when I asked them about, as I'm using a hardly used window manager, IceWM. It turned out that when I changed the theme within my window manager, e.g. to something with a narrow window border, the menu pops up slightly more to the right than when using a theme with thick borders.

Even more, when I temporarily changed to Openbox, the behaviour was as you described and the menu always popped up outside of the cursor. Also, when right-clicking to the bottom of the screen there was no longer a gap between the cursor and the bottom of the menu.

(In reply to :Gijs (slow, PTO recovery mode) from comment #1)
> Reporter: if you're able to run mozregression (
> https://mozilla.github.io/mozregression/ ) then please use that to narrow
> down when this regressed.

I ran mozregression (nice tool, BTW!), but I wasn't able to find the change, i.e. even back in the beginning of 2016 (47.0a1) the bug appeared. It seems it always pops up in nightly and beta versions, but not in release versions. As a quick test, I installed firefox-beta-bin 51.0rc2 and the bug showed up. Does this make sense? If you want me to, I can easily install older beta versions (back to 39.0b5).

Comment 5

[Marcel]

(In reply to Karl Tomlinson (:karlt) from comment #3)
> Given this is happening in content, but not chrome, it sounds similar to bug
> 1400238.  Perhaps it is the same issue, even though the offset was reversed
> in that report.  That is fixed in 58, so it would be helpful to test to see
> whether this is also fixed.  If testing Nightly, then use a separate
> profile.

I also tested nightly (20171109-firefox-58.0a1.en-US.linux-x86_64.tar.bz2) but that version also exhibits this behaviour.

Comment 6

[Marcel]

When using IceWM release 1.4.2 from https://github.com/bbidulock/icewm this issue seems resolved using RC 3 and release 57.0, even when using the firefox-beta-bin package in Arch Linux' User Repository (which until now showed up the issue using IceWM 1.3.8 from SourceForge).

If you want me to, I can test the released version of Arch Linux' official package using IceWM 1.3.8 (which is also the version in the official repositories) within a few days (as 57.0 arrives in official repos).

Comment 7

[Marcel]

Now that the Arch developers released the official package for Firefox 57.0, I just tested that one under IceWM 1.3.8 and the issue is still there. However, using the mentioned fork of IceWM this problem is solved (but other bugs are there, for which I file(d) separate issues).

Comment 8

[Jim Mathies [:jimm]]

(In reply to Marcel from comment #7)
> Now that the Arch developers released the official package for Firefox 57.0,
> I just tested that one under IceWM 1.3.8 and the issue is still there.
> However, using the mentioned fork of IceWM this problem is solved (but other
> bugs are there, for which I file(d) separate issues).

So basically a bug in IceWM 1.3.8?

Comment 9

[Marcel]

That might be the case, although I can't find any changes in the commit logs that sound like fixing GTK-menus or size of window decorations (in the repo at https://github.com/bbidulock/icewm).

Comment 10

[Nico Grunbaum [:ng, @chew:mozilla.org]]

@karlt, @marcel: I am seeing this issue with a stock Ubuntu 18.10 desktop install. I too was experiencing the issue with Nightly but not with release. I noticed that in Nightly I had the title bar disabled (from customize in the hamburger menu). Turning on the title bar seems to have fixed it to the extent that I haven't been able to make it happen so far since. However turning off the title bar in release didn't seem to induce the problem.

Comment 11

[Karl Tomlinson (:karlt)]

Nico, it sounds like your bug has a different cause, because this one is not a regression but you have discovered a regression.
The feature to turn off the title bar is more recent than this bug. If you can file a separate bug for your regression, then please CC :stransky.