Closed Bug 1226948 Opened 4 years ago Closed 4 years ago
Nightly failed to display webpage after minimizing
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20151121030232 Steps to reproduce: Enter some YouTube video. Minimize Nightly. Go back after some time. Actual results: Nightly failed to display webpage. Minimizing or resizing Nightly doesn't help. You can see this here: https://youtu.be/G1A0qfcz9lk I noticed later that opening new tab solves the problem. This is very similar to this bug:https://bugzilla.mozilla.org/show_bug.cgi?id=1209734, but it didn't attract serious attention. My graphics information: Graphics Adapter Description Intel(R) HD Graphics 5500 Adapter Description (GPU #2) NVIDIA GeForce GTX 850M Adapter Drivers igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32 Adapter Drivers (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um Adapter RAM Unknown Adapter RAM (GPU #2) 4095 Asynchronous Pan/Zoom wheel input enabled Device ID 0x1616 Device ID (GPU #2) 0x1391 Direct2D Enabled true DirectWrite Enabled true (10.0.10586.0) Driver Date 8-24-2015 Driver Date (GPU #2) 11-13-2015 Driver Version 10.18.15.4279 Driver Version (GPU #2) 10.18.13.5900 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 229c103c Subsys ID (GPU #2) 229c103c Supports Hardware H264 Decoding Yes Vendor ID 0x8086 Vendor ID (GPU #2) 0x10de WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics 5500 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0
I tried also with better graphic card, NVIDIA, but the problem didn't disappear, so it's rather Nightly issue.
Component: Untriaged → Graphics
OS: Unspecified → Windows 10
Product: Firefox → Core
Thanks for the report. If the problem is not seen using a release build it would be very useful if you could run mozregression: http://mozilla.github.io/mozregression/ This will help us pin-point which change is responsible so that we can avoid releasing that change.
I don't understand. "If the problem is not seen using a release build" - do you mean stable version of Firefox? Or do I have to create a fresh profile?
I mean the stable version of Firefox. If this recently broke we can catch broke it before it makes it to release. mozregression is useful in finding out what that thing is.
Just to ensure - stable version = Firefox 42 official release?
Ok, I have done that. This tool is very nice. Attachment contains photo of the results.
(In reply to to_du from comment #6) > Created attachment 8691584 [details] > regression > > Ok, I have done that. This tool is very nice. Attachment contains photo of > the results. Please click the last result, "2015-11-12", and copy&paste the Bisect information to this bug report.
app_name: firefox build_date: 2015-11-12 build_file: c:\users\hpp\appdata\local\temp\tmpev6a6z\2015-11-12--mozilla-central--firefox-45.0a1.en-US.win64.zip build_type: nightly build_url: https://archive.mozilla.org/pub/firefox/nightly/2015/11/2015-11-12-03-02-38-mozilla-central/firefox-45.0a1.en-US.win64.zip changeset: 3cc3b1968524248450c465c4ea2ee5596ffa65f2 pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc473fe5dc512c450634506f68cbacfb40a06a23&tochange=3cc3b1968524248450c465c4ea2ee5596ffa65f2 repo_name: mozilla-central repo_url: https://hg.mozilla.org/mozilla-central task_id: None
Does somebody apart of me reproduce this?
(In reply to to_du from comment #9) > Does somebody apart of me reproduce this? I have not personally seen this issue nor have I heard of reports from other users but that doesn't necessarily mean it's just you. Benoit, the pushlog above is pretty big but does something jump out at you as a potential cause? If not we may need to get to_du to bisect this further on inbound.
Sorry for the delay. Did the tool not offer you to bisect on inbound? This list is too large with several suspect changes in the graphics/layout module that could account for this. It would help greatly if we can bisect down to a single change. It's possible that the GUI app doesn't support inbound bisection and that you might need to use the command line tool.
I am able to do it, but nobody ask me to do it ;).
(In reply to to_du from comment #6) > Created attachment 8691584 [details] > regression > > Ok, I have done that. This tool is very nice. Attachment contains photo of > the results. From attached regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc473fe5dc512c450634506f68cbacfb40a06a23&tochange=3cc3b1968524248450c465c4ea2ee5596ffa65f2 The most suspicious: 67da9ced67f1 George Wright — Bug 1098131 - Don't invalidate layers when simply changing SizeMode r=smaug,jimm
app_name: firefox build_date: 2015-11-13 05:41:38.849000 build_file: c:\users\hpp\appdata\local\temp\tmpd5cpb9\0c648a1efbe0--mozilla-central--firefox-45.0a1.en-US.win64.zip build_type: inbound build_url: https://queue.taskcluster.net/v1/task/joElWb60TayPi1IC-HD_Lw/runs/0/artifacts/public%2Fbuild%2Ffirefox-45.0a1.en-US.win64.zip changeset: 0c648a1efbe06b5ec866ba058d18256b80808b46 pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3cc3b1968524248450c465c4ea2ee5596ffa65f2&tochange=0c648a1efbe06b5ec866ba058d18256b80808b46 repo_name: mozilla-central repo_url: https://hg.mozilla.org/mozilla-central task_id: joElWb60TayPi1IC-HD_Lw I hope it will help. I have to test several inbound builds ;).
I think I have understood it a little. I have noticed that simply this program is still bisecting and can not find another build. So here are informations from the latest tested build. app_name: firefox build_date: 2015-11-13 01:01:10.335000 build_file: c:\users\hpp\appdata\local\temp\tmpd5cpb9\285852de5cd5--mozilla-central--firefox-45.0a1.en-US.win64.zip build_type: inbound build_url: https://queue.taskcluster.net/v1/task/GURSZNOgQ7e2X_1wPCeMHg/runs/0/artifacts/public%2Fbuild%2Ffirefox-45.0a1.en-US.win64.zip changeset: 285852de5cd54891d8f3b1ddbff179e4c9c7ca5f pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3cc3b1968524248450c465c4ea2ee5596ffa65f2&tochange=285852de5cd54891d8f3b1ddbff179e4c9c7ca5f repo_name: mozilla-central repo_url: https://hg.mozilla.org/mozilla-central task_id: GURSZNOgQ7e2X_1wPCeMHg After this build, program can not find earlier build.
I tried to do it one more time, but the same happened - after build 285852de from 13.11.2015 01:01:10.335000 program keeps searching for next build and can not do it.
you can download firefox-45.0a1.en-US.win64.zip file inbound build from http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64/ Please try each from 1447277373/ to 1447388376/
This should have been fixed by the fix for bug 1234049. Can you reproduce with the latest nightly? I see from your about:support that the builds are quite old (this fix would have started in the January 18th Nightly)
Hmm, I have tested another time, this time setting differently days with the similar effect like before, but fortunately, after George's post I tested this in the latest Nightly and it doesn't appear :-D So I think there is no need to continue this bug ;) This bug was present surely 3 months ago. When Benoit came back to this, I haven't checked whether it still persists ;)
Great, sorry for taking so long to get back to this bug but I'm glad it's fixed. Thanks for doing the regression windows that was very useful!
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1234049
You need to log in before you can comment on or make changes to this bug.