1234049 - Some Web sites go black upon maximizing window

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[WaltS48 [:walts48]]

Attachment: Weather Underground

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

Steps to reproduce:

Start Nightly with a test profile
Load some web sites individually like Weather Underground, Weather Channel, or ABC News

http://www.wunderground.com/
http://www.weather.com/
http://abcnews.go.com/

Minimize Nightly to do something in another application
After a minute or more maximize Nightly to continue browsing


Actual results:

GUI displays, but the sites are black


Expected results:

The sites should display normally

Comment 1

[WaltS48 [:walts48]]

Attachment: Weather Channel

Comment 2

[WaltS48 [:walts48]]

Attachment: ABC News

Comment 3

[Felix]

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build-ID: 20151219030215

Hi WaltS48,
I can confirm this error with Windows 7 x64 and Firefox Nightly 46.0a1 (2015-12-19).

System: Windows x64 + Linux x64

Felix

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Please post your Graphic section from about:support

Comment 5

[WaltS48 [:walts48]]

Graphics
--------

Adapter Description: NVIDIA Corporation -- GeForce GT 630/PCIe/SSE2
Asynchronous Pan/Zoom: wheel input enabled
Device ID: GeForce GT 630/PCIe/SSE2
Driver Version: 4.5.0 NVIDIA 352.63
GPU Accelerated Windows: 0/1 Basic (OMTC)
Supports Hardware H264 Decoding: No;
Vendor ID: NVIDIA Corporation
WebGL Renderer: NVIDIA Corporation -- GeForce GT 630/PCIe/SSE2
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0
CairoUseXRender: 1

Comment 6

[Alice0775 White]

I can reproduce on Nightly46.0a1 32bit with/without HWA.

https://hg.mozilla.org/mozilla-central/rev/388bdc46ba51ee31da8b8abe977e0ca38d117434
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20151220030223

Comment 7

[Alice0775 White]

[Tracking Requested - why for this release]: Regression 

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=81e5c1bef9e33761f7502ee0befce953da367f2a&tochange=67da9ced67f16a37d6bf80966334af1b6d03c67e

Regressed by: 67da9ced67f1	George Wright — Bug 1098131 - Don't invalidate layers when simply changing SizeMode r=smaug,jimm

Comment 8

[Alice0775 White]

STR
1. Maximize browser window
2. Open http://www.weather.com/ and wait to load the page
3. Exit browser
4. Start browser
5. Click "Restore Previous Session" and then very QUICKLY minimize browser
6. Wait for 5-10sec and then Restore browser(i.e maximized)
7. Repeat Step3-7, if necessary.

Actual Results
Content is black

Comment 9

[Felix]

Graphic Details:
Adapter Description	Intel(R) HD Graphics 4000
Adapter Drivers	igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32
Adapter RAM	Unknown
Asynchronous Pan/Zoom	wheel input enabled
Device ID	0x0166
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17292)
Driver Date	9-30-2014
Driver Version	10.18.10.3958
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	500217aa
Supports Hardware H264 Decoding	Yes
Vendor ID	0x8086
WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Felix

Comment 11

[arni2033]

Attachment: (arni2033) Troubleshooting Information 2016.01.02 08-01-05.xht

Disabling hardware acceleration doesn't solve the issue. Safe mode doesn't solve the issue.

I just encountered it on Firefox DE. STR:
 1. Open this bug page in browser with e10s enabled
 2. Click reload button in urlbar, then immediately press Win+D to minimize browser
 3. Wait 10 seconds, then press Win+D to restore browser window's position
Result:   All content rectangle is black with 1px white border. Sometimes content is just white.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Jim, does it ring a bell? thanks

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Tracking because black screen is kind of a trauma (OMTC)...

Comment 14

[George Wright (:gw280) (needinfo me!)]

This is likely a dupe of bug 1227373. Given that this affects Windows as well, and not just Linux with a tiling WM, we should probably block on this.

Comment 16

[George Wright (:gw280) (needinfo me!)]

So here's what's going on:

- In bug 1098131 I added some logic to not throw away layer data upon minimise, and then invalidate/paint everything again upon restore. I did this by adding a new parameter to PresShell::SetIsActive() called aIsHidden, which defaulted to true (true meaning "throw away data"). Minimise/unminimise called SetIsActive with aIsHidden = false.
- In this case, we're creating a new PresShell whilst the browser is minimised. When we minimised, we called SetIsActive and ensured none of the layer data got thrown out, but we then created a new PresShell which queried the DocShell (PresShell::QueryIsActive()) which was inactive, so we called PresShell::SetIsActive without a parameter for aIsHidden, so it defaulted to true. This caused us to call TabChild::MakeHidden which threw away all our stuff.
- When the window was restored, we called SetIsActive again to reactivate the PresShell, but because it came via an unminimise event, aIsHidden was false and so we never invalidated/painted.

It seems to me like the correct thing to do here is to ensure that we always do the invalidation/paint when restoring a window if the PresShell was created whilst it's inactive. Therefore, I've left it the way it is where it called TabChild::MakeHidden when creating the new PresShell, and added a bool to keep track of whether we've called TabChild::MakeHidden and always call MakeVisible/invalidate/paint whenever that bool is showing true.

Comment 17

[George Wright (:gw280) (needinfo me!)]

Attachment: 0001-Bug-1234049-Ensure-we-always-invalidate-new-PresShel.patch

Comment 18

[George Wright (:gw280) (needinfo me!)]

Comment on attachment 8707631 [details] [diff] [review]
0001-Bug-1234049-Ensure-we-always-invalidate-new-PresShel.patch

As per :tn's request, bumping this to smaug who reviewed the original patch that caused this regression.

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/51a497ce4ca0

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/51a497ce4ca0

Comment 21

[George Wright (:gw280) (needinfo me!)]

Comment on attachment 8707631 [details] [diff] [review]
0001-Bug-1234049-Ensure-we-always-invalidate-new-PresShel.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1098131
[User impact if declined]: when browser is unminimised the content area can show black (no content)
[Describe test coverage new/current, TreeHerder]: m-c + local testing
[Risks and why]: low risk; fix was isolated to a small area that makes this edge case behave the same way as it did before 1098131 landed.
[String/UUID change made/needed]: none

Comment 23

[Ryan VanderMeulen [:RyanVM]]

While this patch has definitely reduced the frequency of the problem for me, I'm still seeing the same basic "window goes blank when restored" issue on occasion :(

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/020925ff1881