Closed Bug 1523721 Opened 11 months ago Closed 10 months ago

When browser window starts maximized, right-click menu doesn't open under mouse cursor

Categories

(Core :: Widget: Gtk, defect)

x86_64
Linux
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
firefox65 --- unaffected
firefox66 --- verified
firefox67 --- verified

People

(Reporter: ori, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Tested with Nightly.

Steps to reproduce:

  1. Create a new profile.
  2. Start Firefox.
  3. If the window is not maximized, maximize it, then open a new window with Ctrl+N.
  4. Right click anywhere on the page. The context menu will open about a titlebar-height below and to the right the cursor position.

This also happens when clicking the mouse wheel with general.autoScroll on. The scroll circle will appear below the cursor, which makes the page start scrolling.

This behavior only happens when the window starts maximized. Once it is resized, the behavior will not happen, even if it's maximized again.

Mozregression points to bug 1490344 as the culprit.

If I set browser.tabs.drawInTitlebar to false, it doesn't happen.

(This bug is unrelated to webrender, as I previously assumed)

Can you attach your about:support page? (there's a button to copy text content to clipboard there). Also which system/distro do you run? I can't reproduce that on Fedora 29. Thanks.

Assignee: nobody → stransky
Flags: needinfo?(ori)

I'm on Ubuntu 18.04 with its distributed version of Gnome. I've tested it with gnome-shell and gnome-flashback.

EDIT: Removed about:support data.

Flags: needinfo?(ori)

Yes, I can reproduce it. It affects only remote web content - when clicking on titlebar/tabs the menu position is correct.

Blocks: gtktitlebar

Recently we quit nsWindow::OnWindowStateEvent()/window_state_event handler when titlebar needs an update due to focus change.
That's incorrect as we need to process other information from the handler - maxminized/normal window state.

Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Duplicate of this bug: 1525233

From bug 1525233, looks like 66 is also affected. Can you request beta uplift? Thanks!

Flags: qe-verify+
Flags: needinfo?(stransky)

Verified as fixed on Firefox Nightly 67.0a1 (2019-02-06) on Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED

Comment on attachment 9041457 [details]
Bug 1523721 - [Linux/Gtk+] Continue processing window_state_event handler when titlebar is updated, r=dao

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1491808

User impact if declined

Wrong popup menu position when system titlebar is disabled as the correct window state event is not saved in nsWindow and menu offset is calculated according an old window state.

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

Yes

If yes, steps to reproduce

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

This patch restores event processing at nsWindow::OnWindowStateEvent() as it was before Bug 1491808.

String changes made/needed

none

Flags: needinfo?(stransky)
Attachment #9041457 - Flags: approval-mozilla-beta?

Comment on attachment 9041457 [details]
Bug 1523721 - [Linux/Gtk+] Continue processing window_state_event handler when titlebar is updated, r=dao

[Triage Comment]
Fixes a popup menu positioning error when system titlebar is disabled on Linux. Approved for 66.0b6.

Attachment #9041457 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified as fixed also on Beta 66.0b6 with Ubuntu 18.04 x64.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.