Web Render Debug Capture Seems to be stuck on filling disk
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: johnpscarrott7777, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
General Browsing, no change from normal
Actual results:
wr-capture folders were created every minute in my appData folder till all disk space was used up.
Expected results:
Not done that
|
||
Comment 1•6 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•6 years ago
|
||
Thank you for the report! We have Ctrl + Shift + 3 assigned to take captures. Could it be that you use this combination for something else in the system and we erroneously capture it?
|
Reporter | |
Comment 3•6 years ago
|
||
No I don't use that shortcut for anything. The only thing I've changed recently near that is added a mouse macro of ctrl+alt+home followed by ctrl+arrow to move virtual desktops after breaking from an rdp session.
I had it twice in the day it happened and thinking about it firefox became weirdly unresponsive before it started capturing. Where the page inside a tab was unresponsive but everything else worked fine. I would then restart Firefox and not notice anything till a couple hours later when my disk was full.
I updated to a later nightly right after submitting the bug and it hasn't happened again.
Is there any use feedback a capture has been triggered I can look out for it it happens again?
Cheers
|
|
||
Comment 4•6 years ago
|
||
We don't log why a capture is triggered, since the only way to do so is to hit that magic combination of keys (that for some reason Firefox thinks you are hitting), so I don't think there is a feedback to use here, other than maybe something our input system logs. Will NI somebody relevant (Masayuki?) :)
It's good to know this is not happened on Nightly. If we find the exact change that got it fixed (by using mozregression), we could back-port it to get the fix faster.
|
||
Comment 5•6 years ago
|
||
I have no idea. "3" can be inputted with numpad, and some shortcut key synthesizer use numpad's "3". I struggled with it in bug 1612238, but it's fixed in 74 and requires Alt key for running the path.
Is the shortcut key declared with XUL <key> element?
|
|
||
Comment 6•6 years ago
|
||
Masayuki, it's defined here - https://searchfox.org/mozilla-central/rev/7fba7adfcd695343236de0c12e8d384c9b7cd237/browser/base/content/browser-sets.inc#331
|
|
Reporter | |
Comment 7•6 years ago
|
||
I have worked it out, it's only ctrl + shift + 3 on mac (According to the link). I'm not on mac and I also assigned ctrl + # for push-to-talk recently. Apparently I was using it pretty regularly but haven't needed it since reporting the bug. Hence why it has gone away.
Is it possible to have some UI feedback that you have triggered a debug capture? Just to let people know they if they are accidentally doing it.
|
|
||
Comment 8•6 years ago
|
||
That's a great idea, we could have some indication showing that a capture is made, where it would be great to point out the destination folder as well.
|
||
Comment 9•6 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)
|
||
Comment 10•4 years ago
|
||
WR debug capture is no longer enabled by default - must be enabled by a flag in about:config.
Description
•