Closed
Bug 1339839
Opened 7 years ago
Closed 2 years ago
Flickering and bad repainting occur after hitting the "Terminate GPU Process" button
Categories
(Core :: Graphics, defect, P3)
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
firefox53 | --- | affected |
People
(Reporter: asimonca, Assigned: dvander)
References
Details
Attachments
(1 file)
24.13 KB,
image/png
|
Details |
[Note]: This happens on most Alexa Topsites, especially on the ones playing video [Affected versions]: - 53.0a2 (id: 20170215004022) [Affected platforms]: - Windows 10 x64 & Windows 7 x86 [Steps to reproduce]: 1. Check about:config if the pref "layers.gpu-process.enabled" is set to "true" 2. Check the Windows task manager for 3 Firefox processes (some of them may be registered as a background process) 3. Add the "layers.gpu-process.max_restarts" integer preference in about:config and set it to 3. 4. Restart Firefox. 5. Go to any site that plays videos from Alexa Top Sites. (e.g. Facebook, Twitter, Youtube, etc.) and play a video. 6. Go to "about:support" and find the "Terminate GPU Process" button in the "Graphics" section, press it and make sure there are only 2 processes left in Task Manager. (1 in Apps & 1 in Background Processes). [Expected result]: - The video continues playing with no issues. (if the video pauses for a second and then resumes it is considered to be expected) [Actual result]: - The video is rendered as a black image while the audio and contextual menus still work. [Regression range]: - Not a regression. New feature. [Additional notes]: - Sometimes a browser crash occurs. We have not been able to find STR for the crashes; sometimes they occur, sometimes they don't. https://crash-stats.mozilla.com/report/index/fba300c4-6f47-407d-b0a4-99e7a2170214
Reporter | ||
Comment 1•7 years ago
|
||
Sometimes the "Actual result" is: - bad repainting of the website - flickering - the site is completely white while the cursor changes when it is hovering where buttons were supposed to be Screen capture: https://drive.google.com/open?id=0B4FHsML7tYx9NHdUQW1IX0huZ1E
Reporter | ||
Comment 2•7 years ago
|
||
Updated•7 years ago
|
Severity: normal → major
Note that setting layers.gpu-process.max_restarts to a non-default value invalidates the testing for 53. Nightly does have that set to 3, but 53/Aurora has it at zero. The behaviour changes completely. We can leave this as a 54 bug, with layers.gpu-process.max_restarts set to > 0 or document what happens with the default preference value here and open another bug for 54/layers.gpu-process.max_restarts > 0.
Assignee: nobody → dvander
(In reply to Milan Sreckovic [:milan] from comment #3) > Note that setting layers.gpu-process.max_restarts to a non-default value > invalidates the testing for 53. Nightly does have that set to 3, but > 53/Aurora has it at zero. The behaviour changes completely. I'd like to clarify this point about testing validity. I've instructed Softvision to test with a value set to 3 in spite that we're not shipping with a value other than 0 to get some early testing on how we handle restarts. The test will ask them the terminate the process three times at various points. With a value of 3 is a third termination not the same as the first termination if the pref is set to 0?
It is certainly not the same for the first termination; hopefully it's the same for the third termination. We'd want the results separated on first vs. last vs. not-last as different things are happening. For example, video decoding comes back in a completely different way for the last vs. not-last.
Reporter | ||
Comment 6•7 years ago
|
||
Frankly, I'm a bit confused as to whether or not to keep the preff "layers.gpu-process.max_restarts" to the value of "3" or just the default value. Another thing that we're concerned about is the matter of crashes. From what I've gathered, it's OK to have a tab crash, but browser crashes not so much. The thing is that the "Terminate GPU Process" button DOES NOT work on the first click every time and when pressing it more times it tends to lead to a BROWSER crash. Should we just ignore those? We've been sending the reports via the crash reporter in the past but I believe we should keep them in check. We are about to start our "pre-Beta" sign-offs and have a new report on this issue by the end of the week.
Flags: needinfo?(milan)
Flags: needinfo?(anthony.s.hughes)
For the purposes of beta testing - use the default value (0) and if it doesn't kill the GPU process on the first click, (wait 30 seconds?), restart Firefox and try again. As in, ignore the results from multiple clicks.
Flags: needinfo?(milan)
Comment 8•7 years ago
|
||
Milan, we started testing this according to your instructions, but we're encountering across the board crashes (not just the gpu process) when using the "Terminate GPU Process" button while videos or GIFs are playing on social media websites, such as Facebook, Twitter and Reddit. Here's a screencast showing exactly what I mean: http://imgur.com/a/0Wkdv and a few crash signatures associated to this scenario: - c6b52039-0a4c-423d-9936-392252170301 (Facebook) - 3cb10538-9755-48aa-a78a-d126a2170301 (Facebook) - c2066056-0bb8-4d5c-a449-278882170301 (Twitter) - 112a1102-0439-473e-a7eb-233912170301 (Reddit) Note that this happens 50% of the time. What's your take on this?
Flags: needinfo?(milan)
Assignee | ||
Comment 9•7 years ago
|
||
(In reply to Cristian Comorasu [:CristiComo] from comment #8) > Milan, we started testing this according to your instructions, but we're > encountering across the board crashes (not just the gpu process) when using > the "Terminate GPU Process" button while videos or GIFs are playing on > social media websites, such as Facebook, Twitter and Reddit. > > Here's a screencast showing exactly what I mean: http://imgur.com/a/0Wkdv > and a few crash signatures associated to this scenario: > - c6b52039-0a4c-423d-9936-392252170301 (Facebook) > - 3cb10538-9755-48aa-a78a-d126a2170301 (Facebook) > - c2066056-0bb8-4d5c-a449-278882170301 (Twitter) > - 112a1102-0439-473e-a7eb-233912170301 (Reddit) > > Note that this happens 50% of the time. What's your take on this? Can you file a bug for these crashes, and CC or assign me? It looks like a video crash that should be easy to fix.
Flags: needinfo?(milan)
Comment 10•7 years ago
|
||
(In reply to Alexandru Simonca, QA (:asimonca) from comment #6) > We are about to start our "pre-Beta" sign-offs and have a new report on this > issue by the end of the week. Hi Alexandru, I agree with what Milan has replied in comment 7. For the purposes of pre-Beta sign off we don't need to repeat testing of multiple restarts and should instead focus on the defaults since that's what we're going to support. I will send you an email with further instructions.
Flags: needinfo?(anthony.s.hughes)
Comment 11•7 years ago
|
||
(In reply to Cristian Comorasu [:CristiComo] from comment #8) > Here's a screencast showing exactly what I mean: http://imgur.com/a/0Wkdv > and a few crash signatures associated to this scenario: > - c6b52039-0a4c-423d-9936-392252170301 (Facebook) > - 3cb10538-9755-48aa-a78a-d126a2170301 (Facebook) > - c2066056-0bb8-4d5c-a449-278882170301 (Twitter) > - 112a1102-0439-473e-a7eb-233912170301 (Reddit) It's hard for me to tell from the screencast if these are taking down the entire browser requiring a restart, or if these are just taking down the GPU Process requiring a tab reload. That said these are all the same signature (@ std::map<T>::operator[]) and deserve a bug report. I would not that we also have these crashes on older Firefox versions so pressing the terminate button may just be a new way to trigger an older issue. I would certainly not block pre-Beta signoff on these.
Updated•7 years ago
|
Priority: -- → P2
Reporter | ||
Comment 13•7 years ago
|
||
Hi, I've been testing the "Compositor Process" feature for the pre-Release feature sign offs on the latest Beta 53.0b7 build and this is a recurring issue. I was testing Facebook Live streams by ending the gpu process straight from the Task Manager, as you can see in the attached videos. The side effects are many: - sometimes the browser crashes altogether [1] - sometimes the whole page goes white, although the functionality of the buttons is not affected [2] - sometimes there are artifacts still present on the page [3] [1] https://goo.gl/hGFuAS [2] https://goo.gl/Vmaqzk [3] https://goo.gl/CrEoo5 I see this as a potential blocker for the pre-Release sign-off. Is there any chance of getting it fixed this week? OS Windows 10 x86 User Agent Mozilla/5.0 (Windows NT 10.0; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID 20170327081421
Flags: needinfo?(milan)
I'm assuming the browser crashes are the same as in comment 8? Or do we have a separate bug opened for those crashes in [1] from comment 13?
Flags: needinfo?(milan) → needinfo?(alexandru.simonca)
Assignee | ||
Comment 15•7 years ago
|
||
(In reply to Alexandru Simonca, QA (:asimonca) from comment #13) > Are these issues reproducible on Nightly as well (in case we fixed a bug that can be uplifted)? If they are broken on Nightly as well, do you have precise STR? I've tried steps similar to these videos and haven't gotten anything yet. The crashes should have been fixed by bug 1331548 and bug 1331761. I'm requesting uplift on those now.
Reporter | ||
Comment 16•7 years ago
|
||
@Milan, the browser crashes are the same as in Comment #8 and all of them have the signature: std::map<T>::operator[] @David, I've just tried out the latest Nightly build and things look good there. I haven't experienced any crashes on Facebook Live, nor on Youtube, Reddit or Twitter. If these get uplifted soon we should be good for going to RC with this feature. It would be great if we could have them in tomorrow's Beta.
Flags: needinfo?(alexandru.simonca)
Comment 17•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Comment 18•2 years ago
|
||
Closing this as resvoled:incomplete since the Terminate GPU Process button is no longer available for use in about:support Graphics section.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•