1741297 - Tab content is blank until changing windows

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[Brian Birtles (:birtles)]

Attachment: about:support

Since about one week ago (i.e. roughly Nov 8 or thereabouts) I frequently encounter a case where the content of all tabs are blank (dark black, but not solid black, presumably because that's the default background color for the theme I've applied).

This persists until I Alt+Tab to another window and back.

I've filed this under Widget: Win 32 because I wonder if it's related to the window occlusion work. Actually, given the timeframe, this is quite likely due to bug 1732736 landing.

Comment 1

[Brian Birtles (:birtles)]

(Sorry, forgot to clarify that this is on Nightly.)

Comment 2

[Sotaro Ikeda [:sotaro]]

:birtles, thank you for reporting! Do you have any ideas about STR to cause the problem? I also use nightly on Windows, but I did not saw the problem.

Comment 3

[Brian Birtles (:birtles)]

(In reply to Sotaro Ikeda [:sotaro] from comment #2)

:birtles, thank you for reporting! Do you have any ideas about STR to cause the problem? I also use nightly on Windows, but I did not saw the problem.

Not yet. I see it about twice every day. I think there may be a short hang before it happens. It might also happen when I am using DevTools a lot.

I will update this bug next time it happens.

Comment 4

[Sotaro Ikeda [:sotaro]]

Thank you:) After the symptom happens, about:support might have error log.

Comment 5

[Sotaro Ikeda [:sotaro]]

:birtles, can you also take screenshot when the problem happens?

Comment 6

[Brian Birtles (:birtles)]

Attachment: Screenshot

Comment 7

[Brian Birtles (:birtles)]

This reproduced for me just now. Before it happened, the browser hung for a few seconds.

I could reproduce the hang fairly consistently but not the tabs going blank effect.

For the hang, generally, the STR was to focus on a number field on https://www.makeshop.jp/ssl/plural_order.html#plural_anchor (need to be actually buying something I think, however), then Alt+Tab to another app (Excel) and back. That would reproduce fairly often, particularly when DevTools was open.

Simply Alt+Tab'ing to another app and back again would resolve the hang.

I managed to take a profile of the hang on one occasion but the tabs didn't go blank afterwards. I will send it to Sotaro directly since it contains private information.

I also checked about:support after the hang but did not see any errors.

Comment 8

[Brian Birtles (:birtles)]

Attachment: about:support immediately after the tabs went blank

Comment 9

[Brian Birtles (:birtles)]

Also, I should mention that taking the screenshot caused the tab to render (since it brought up the SnagIt snapshot tool which renders an overlay over the entire screen). Fortunately it captured the screen before triggering the render.

Comment 10

[Sotaro Ikeda [:sotaro]]

Hmm, Attachment 9250872 [details] did not have gfx error log.

Comment 11

[Sotaro Ikeda [:sotaro]]

For the hang, generally, the STR was to focus on a number field on https://www.makeshop.jp/ssl/plural_order.html#plural_anchor (need to be actually buying something I think, however), then Alt+Tab to another app (Excel) and back. That would reproduce fairly often, particularly when DevTools was open.

:birtles, was DevTools shown as separate window? Or dock to window?

Simply Alt+Tab'ing to another app and back again would resolve the hang.

I wonder if "Alt+Tab'ing" is related to the problem, since window occlusion has a code that is specific to "Alt+Tab'ing".

• https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/widget/windows/WinWindowOcclusionTracker.cpp#1194
• https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/widget/windows/WinWindowOcclusionTracker.cpp#1218

Comment 12

[Brian Birtles (:birtles)]

(In reply to Sotaro Ikeda [:sotaro] from comment #11)

For the hang, generally, the STR was to focus on a number field on https://www.makeshop.jp/ssl/plural_order.html#plural_anchor (need to be actually buying something I think, however), then Alt+Tab to another app (Excel) and back. That would reproduce fairly often, particularly when DevTools was open.

:birtles, was DevTools shown as separate window? Or dock to window?

Docked to the side of the window. I encountered the problem without DevTools showing, however, so it is not necessarily related. (The hang seemed to be more frequent when DevTools was open but that might be coincidence.)

Simply Alt+Tab'ing to another app and back again would resolve the hang.

I wonder if "Alt+Tab'ing" is related to the problem, since window occlusion has a code that is specific to "Alt+Tab'ing".

Yes, it seemed like Alt+Tab'ing would resolve the hang and also resolve the "all tabs are blank" problem.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 14

[Brian Birtles (:birtles)]

This happened again just now and I didn't notice any hang before it happened.

Interestingly as I cycled between the different tabs, they were all blank except the about:newtab page.

Comment 15

[Brian Birtles (:birtles)]

Attachment: Screenshot of another occurrence

Unlike last time I didn't have multiple windows open, nor was 1Password active, nor was there a pending update.

Comment 16

[Sotaro Ikeda [:sotaro]]

(In reply to Brian Birtles (:birtles) from comment #14)

This happened again just now and I didn't notice any hang before it happened.

Interestingly as I cycled between the different tabs, they were all blank except the about:newtab page.

I wonder if the window was nsWindow::mIsFullyOccluded was kept true when the problem happened.

• https://searchfox.org/mozilla-central/rev/6deb8b6af57a8b5b6b1bcb143ea498e566475d8d/widget/windows/nsWindowGfx.cpp#430

:birtles, can you get moz log out put when the problem happens?
moz log could be saved from about:networking#logging with "WinOcclusionTracker:3,WinOcclusionCalculator:3,Widget:3".
When I tested, the moz log was written when Firefox was closed.

The following could be used for local build.

MOZ_LOG=WinOcclusionTracker:3,WinOcclusionCalculator:3,Widget:3 ./mach run > log.txt 2>&1

Thank you.

Comment 17

[Brian Birtles (:birtles)]

(In reply to Sotaro Ikeda [:sotaro] from comment #16)

(In reply to Brian Birtles (:birtles) from comment #14)

This happened again just now and I didn't notice any hang before it happened.

Interestingly as I cycled between the different tabs, they were all blank except the about:newtab page.

I wonder if the window was nsWindow::mIsFullyOccluded was kept true when the problem happened.

• https://searchfox.org/mozilla-central/rev/6deb8b6af57a8b5b6b1bcb143ea498e566475d8d/widget/windows/nsWindowGfx.cpp#430

:birtles, can you get moz log out put when the problem happens?
moz log could be saved from about:networking#logging with "WinOcclusionTracker:3,WinOcclusionCalculator:3,Widget:3".
When I tested, the moz log was written when Firefox was closed.

Thanks! I am trying that now.

Unfortunately the problem only occurs 1~2 times a day.

I set the logging parameters yesterday but when the problem occurred today, I noticed the logging parameters had been reset so there was no information.

I have re-set the logging parameters. Hopefully the problem will occur again soon 🤞

Comment 18

[Sotaro Ikeda [:sotaro]]

Thank you! I am going to try to add an easier way to visually check if window is currently fully occluded or not.

Comment 19

[Selim Şumlu]

I've been experiencing the same problem lately. (See bug 1742131)

Here's my about:config if it helps: https://pastebin.mozilla.org/4Yx0kaoh

And I rarely use DevTools, so I don't think it's the culprit.

Comment 21

[Sotaro Ikeda [:sotaro]]

Bug 1742241 might be caused by Bug 1687926.

Comment 22

[Sotaro Ikeda [:sotaro]]

I seemed to find the STR to cause the problem with patch of Bug 1742440. D131807 could be used to check an occlusion state visually.

• [1] Open Firefox
• [2] Cover the Firefox by other window like chrome browser
• [3] Push Windows］+ D several times
• [4] Choose the Firefox by Alt+Tab and check the occlusion state

On [4], if Occlusion is not "is_fully_occluded:true"(red), return to [2].

There was a case that the Firefox's occlusion state was still "is_fully_occluded:true" on [4].

Comment 23

[Brian Birtles (:birtles)]

Thank you!

Do you still need me to generate logs for this? I'm sorry I haven't been able to yet--I have to reset the log parameters each time I restart Firefox and the bug generally reproduces before I remember!

Comment 24

[Brian Birtles (:birtles)]

Today I was performing a lot of edits in a Google Doc while Alt+Tabbing between that doc and another (Firefox) window. I noticed that the Google Doc would sometimes appear unresponsive. However, if I Alt+Tab to the other window and back it would be fixed.

I suspect this is a variant of this bug where the Google Doc was actually being updated but the changes were not being rendered. (FWIW, this particular Google Doc was in the new canvas-mode.)

Comment 25

[Sotaro Ikeda [:sotaro]]

(In reply to Brian Birtles (:birtles) from comment #23)

Thank you!

Do you still need me to generate logs for this? I'm sorry I haven't been able to yet--I have to reset the log parameters each time I restart Firefox and the bug generally reproduces before I remember!

Thank you very much. I do not need the log for now.

Comment 26

[Sotaro Ikeda [:sotaro]]

It seems that when the problem happened, select background app by Alt+Tabbing did not trigger ScheduleOcclusionCalculationIfNeeded().

Comment 27

[Sotaro Ikeda [:sotaro]]

:birtles, can you check window visibility state when the problem happens with latest nightly?

window visibility state could be checked with pref "gfx.webrender.debug.window-visibility:true". It enables debug overlay.
When window state is fully occluded, the overlay shows "is_fully_occluded:true" with red color.

Comment 28

[Sotaro Ikeda [:sotaro]]

D132206 of Bug 1743057 addressed the problem of STR of comment 22 for me.

Comment 29

[Brian Birtles (:birtles)]

(In reply to Sotaro Ikeda [:sotaro] from comment #27)

:birtles, can you check window visibility state when the problem happens with latest nightly?

window visibility state could be checked with pref "gfx.webrender.debug.window-visibility:true". It enables debug overlay.
When window state is fully occluded, the overlay shows "is_fully_occluded:true" with red color.

The problem just occurred for me an I can confirm that the overlay was red for the window in question.

Comment 30

[Sotaro Ikeda [:sotaro]]

Thank you for the confirmation.

Comment 31

[Sotaro Ikeda [:sotaro]]

:birtles, can you check if the problem is addressed with latest nightly?

Comment 32

[Brian Birtles (:birtles)]

It hasn't occurred yet today so I think it might be fixed! I will let you know if it happens again. Thank you!

Comment 33

[Sotaro Ikeda [:sotaro]]

Good! Thank you for the confirmation.