All users were logged out of Bugzilla on October 13th, 2018
36.57 KB, image/png
33.28 KB, image/png
40.80 KB, image/png
44.17 KB, application/xhtml+xml
2.99 KB, patch
|Details | Diff | Splinter Review|
Created attachment 8700399 [details] 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
Attachment #8700400 - Attachment description: Weather Chanel → Weather Channel
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
Please post your Graphic section from about:support
Severity: normal → major
Component: Untriaged → Graphics
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → x86_64
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
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
[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
Status: UNCONFIRMED → NEW
status-firefox44: --- → unaffected
status-firefox45: --- → affected
status-firefox46: --- → affected
tracking-firefox45: --- → ?
tracking-firefox46: --- → ?
Ever confirmed: true
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
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
Assignee: nobody → gwright
Created attachment 8703311 [details] (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.
Summary: Some Web sites go black in Nightly 46.0a1 upon maximizing window → Some Web sites go black upon maximizing window
Jim, does it ring a bell? thanks
Tracking because black screen is kind of a trauma (OMTC)...
tracking-firefox45: ? → +
tracking-e10s: --- → ?
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.
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.
Created attachment 8707631 [details] [diff] [review] 0001-Bug-1234049-Ensure-we-always-invalidate-new-PresShel.patch
Attachment #8707631 - Flags: review?(tnikkel)
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.
Attachment #8707631 - Flags: review?(tnikkel) → review?(bugs)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox46: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
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
Attachment #8707631 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 1227373
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 :(
Attachment #8707631 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox45: affected → fixed
You need to log in before you can comment on or make changes to this bug.