1827429 - Recently opened Firefox window on Wayland may be empty / fully transparent

Status: RESOLVED FIXED

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

Description

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

In case newly opened window is not immediately visible (for instance is opened by remote instance), the window is created as occluded and can't be flipped back to visible.

We need to call explicitly NotifyOcclusionState(VISIBLE) from OnExposeEvent() to fix that as we know the window is visible.

Comment 1

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Attachment: Bug 1827429 [Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r?emilio

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2b8b117022c
[Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r=emilio

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f2b8b117022c

Comment 4

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Comment on attachment 9327942 [details]
Bug 1827429 [Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: Newly opened Firefox window may be invisible/empty on Wayland.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• 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): We enable rendering (set visible occlusion state) in Expose event which paints Firefox window.
  We used VSync for that only before this patch.
• String changes made/needed:
• Is Android affected?: No

Comment 5

[Pascal Chevrel:pascalc]

Comment on attachment 9327942 [details]
Bug 1827429 [Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r?emilio

Approved for 113 beta 3, thanks.

Comment 6

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/a559fcdcfccf

Comment 8

[Mike Kaply [:mkaply]]

Comment on attachment 9327942 [details]
Bug 1827429 [Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: Flatpak doesn't display sometimgs
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• 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): GTK only fix has been verified.
• String changes made/needed:
• Is Android affected?: No

Comment 9

[Mike Kaply [:mkaply]]

If we do another dot release, it would be nice to grab this.

Comment 10

[Dianna Smith [:diannaS]]

Comment on attachment 9327942 [details]
Bug 1827429 [Wayland] Call NotifyOcclusionState(OcclusionState::VISIBLE) from nsWindow::OnExposeEvent() as we know the window is visible r?emilio

Approved for 112.0.2 dot release

Comment 11

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-release/rev/48bcf011c5d5