1906358 - Window open animation no longer works

Status: NEW

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

Description

[Masatoshi Kimura [:emk]]

Steps to reproduce:

1. Launch Firefox.
2. Press Ctrl+N to open a new window.

Actual result:
Window will appear without fade-in animation.

Expected result:
Window should appear with fade-in animation.

This is a regression from bug 1824053. Show-then-uncloak breaks the window open animation.

Comment 1

[Masatoshi Kimura [:emk]]

I think we should cloak/uncloak only when mOpeningAnimationSuppressed is true. If opening animation is enabled, white flash is unobtrusive (it is the reason the STR in bug 1824053 detaches a window. The opening animation is suppressed in this case).

Comment 2

[BugBot [:suhaib / :marco]]

:rkraesig, since you are the author of the regressor, bug 1824053, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Ray Kraesig [:rkraesig]]

(In reply to Masatoshi Kimura [:emk] from comment #1)

If opening animation is enabled, white flash is unobtrusive

Our users seem to disagree — most recently here, but also in videos in bug 1891151 and bug 1898593.

I suspect you're operating in a well-lit room with reasonable contrast. Try setting Windows to dark mode, then turning off the lights — a white flash is difficult to describe as "unobtrusive" under these conditions! You may also be running Windows 11, as I'm not sure there's a window-opening animation in Win10 at all. (I have tested on Win11, though, and I don't think the window-opening animation is sufficient to mitigate the white flash in dark conditions.)

It may be worth disabling show-then-uncloak if we're in light mode. We might even be able to do some silliness like "cloak, show, clear-to-black, hide, uncloak, show" if we really wanted to preserve the animation, but I don't think it's worth the additional latency it would generate.

Comment 4

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1824053

Comment 5

[Donal Meehan [:dmeehan]]

:rkraesig Fx129 is now in beta, I see this was triaged as P3/S4.
This is on the regression triage dashboard https://bugdash.moz.tools/#tab.reo
Wondering if you plan on having a fix in time for Fx129 and/or Fx130, or this is in the backlog to come in a later release?

Comment 6

[Ray Kraesig [:rkraesig]]

This is in the backlog. I don't think we have a good solution to this bug that doesn't regress the previous one, and simply skipping the window-open animation seems the least of all available evils.

Comment 8

[Masatoshi Kimura [:emk]]

Please consider using WS_EX_NOREDIRECTIONBITMAP to disable redirection bitmaps that are causing a white flash.

We will have to check if compositor windows are available before the first compositor window is created. Because WS_EX_NOREDIRECTIONBITMAP will make windows invisible if compositor windows are not used (for example, when hardware acceleration is disabled).

Comment 9

[Ray Kraesig [:rkraesig]]

(In reply to Masatoshi Kimura [:emk] from comment #8)

Because WS_EX_NOREDIRECTIONBITMAP will make windows invisible if compositor windows are not used (for example, when hardware acceleration is disabled).

Unfortunately, we can't toggle WS_EX_NOREDIRECTIONBITMAP in mid-flight; the HWND has to be torn down and recreated. Therefore, if we disable redirection surfaces on our windows, we can no longer fall back to non-accelerated rendering in mid-session if the GPU process is unstable. (I'm aware there are plans to stop doing that — see e.g. bug 1870021 — but I'm not sure how far those have actually proceeded.)

Additionally, the skeleton UI is currently drawn using GDI calls, because (AIUI) hardware acceleration is never available at that time. Removing the redirection surface from that first window means that the skeleton UI won't be drawn at all. This is less of a problem because we could probably disable redirection surfaces only for subsequent HWNDs; I don't think that would cause any issues beyond some annoying additional bookkeeping on our end.

Comment 10

[Ray Kraesig [:rkraesig]]

(In reply to Ray Kraesig [:rkraesig] from comment #9)

(In reply to Masatoshi Kimura [:emk] from comment #8)

Because WS_EX_NOREDIRECTIONBITMAP will make windows invisible if compositor windows are not used (for example, when hardware acceleration is disabled).

Unfortunately, we can't toggle WS_EX_NOREDIRECTIONBITMAP in mid-flight; the HWND has to be torn down and recreated. Therefore, if we disable redirection surfaces on our windows, we can no longer fall back to non-accelerated rendering in mid-session if the GPU process is unstable. (I'm aware there are plans to stop doing that — see e.g. bug 1870021 — but I'm not sure how far those have actually proceeded.)

Addendum: As a result of some mostly-unrelated research, I now suspect it might be possible (at least in theory!) to use DirectComposition even without hardware acceleration. If we could separate DComp from hardware acceleration and simply always use it, I think this would allow us to simplify our painting code, and in particular, drastically reduce the complexity of supporting translucent or partially-transparent windows on Windows (bug 1911763).

Comment 12

[anixxsus]

Hello! This patch also causes bug https://bugzilla.mozilla.org/show_bug.cgi?id=1950145