Webextension hang causes browser hang
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: bytesized, Unassigned, NeedInfo)
Details
Attachments
(1 file)
|
31.76 KB,
image/png
|
Details |
extension_icons.PNG
I want to apologize in advance, because this bug report is going to be a bit of a mess. I'm not even sure the title is accurate. But I've seen this problem a couple of times and I feel like I need to file a bug. Unfortunately, I cannot provide reliable STR.
Here is what happens:
- I control+click on a link
- I switch to the new tab
- Since I use the NoScript webextension, the page doesn't display properly. I decide to allow some of the JS on the page, so I click the NoScript icon to activate the browser action.
- Sometimes the NoScript window has some sort of Flash of Content at this point, but then it removes the content. Either way, I end up with a 0-height window.
- I get impatient and click outside the window, thinking I'll just close it and reopen it. The windows closes.
After this, Firefox gets into a weird state. Clicking the buttons for my extensions causes them to appear "clicked", but to do nothing. The hamburger menu button has the same behavior. I cannot switch to another tab. Eventually I close the tab I am in. This takes a moment, but it does close and then all the actions I performed suddenly take effect. Extension windows and the hamburger menu all open, one after another (I believe in the order I clicked them). I end up on the tab I was trying unsuccessfully to switch to before I closed the "problem tab".
If I try to visit the site from the "problem tab" again, it seems to work fine.
I'm attaching a screenshot of the buttons in their "clicked" state, but not doing what they are supposed to do.
|
||
Comment 1•4 years ago
|
||
This sounds to me like the WebExtension process is not responding. It would be good to get a sense of what the WebExtension process is doing when this happens. If it's fully hung, getting a profile isn't to work. If you're on macOS you could get an Process Sample from the Activity Monitor. If you're on Linux, maybe just attaching gdb to the WebExtension process and getting a backtrace would work. On Windows, attaching VC++ and getting a backtrace might be helpful.
However, if the process isn't fully hung, but actually just bogged down - a profile might be useful after the process has freed up.
|
Reporter | |
Comment 2•4 years ago
|
||
I think I've seen this on both macOS and Windows. If I see it again soon, I'll try to do what you are suggesting and post the results.
|
||
Comment 3•4 years ago
|
||
This looks similar to bug 1355239. Leaving open for a bit to see if Kirk can provide more info, otherwise we'll close as dupe.
|
|
Reporter | |
Comment 4•4 years ago
|
||
I haven't seen this happen again since I reported it. Let's assume that it's a dup of bug 1355239.
|
|
Reporter | |
Comment 5•4 years ago
|
||
I've continued to see this issue, but it's infrequent, so it's been hard to pin down. I got this profile, which I started after the problem had started happening. I haven't really tried to take a close look at in, but that long red bar in the webextensions map seems like it coincides pretty closely with the time range when I was experiencing the problem, so maybe there's something helpful in there.
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 7•4 years ago
|
||
Just taking a very quick look at the profile, I can see that this issue actually outlives the red bar. You can tell by the screen shots (you can see the extension icons looking like they do in the attachment I posted to this bug). It looks like things unfreeze at around the 88s mark.
|
|
||
Comment 8•4 years ago
|
||
There's an incorrect jank marker in there - what I thought was us being blocked on a mutex lock was actually the main thread of the WebExtension process just idling. Sorry about the noise.
|
|
||
Comment 9•4 years ago
|
||
So I've had a closer look at this, and what really stands out to me is the paints happening on the main thread in the parent process. They're super frequent. In this one 16ms slice of the profile, I'd expect to see 1 frame paint attempt: https://share.firefox.dev/35ItNVO
Instead, I see 4. I wonder if the compositor is just getting completely overwhelmed with traffic.
Hey jrmuizel, am I reading this right? If so, do you know why we would be painting and uploading so frequently?
Description
•