Crash if you tear a tab with Unity WebGL, and put it back
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox112 | --- | fixed |
People
(Reporter: mayankleoboy1, Assigned: sotaro)
References
()
Details
Crash Data
Attachments
(2 files)
Use fresh nightly profile
Open 2 tabs
Tab A : Google.com
Tab B : https://gaprot-webgl.web.app/
Make sure that Tab B is always in focus
Let the Tab B load till the time the animation starts (the lights on the floor of the animation start blinking)
Tear away Tab B from the Nightly Window to create a new Window
Re-attach Tab B into the original Nightly Window
Repeat detaching and re-attaching the Unity tab a couple of times till you get a crash
AR: Crash
Reporter | ||
Comment 1•2 years ago
|
||
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
Also repros on a much simpler page: https://lab.hakim.se/hypnos/
You might need to create 6-8 duplicate tabs of the demo page, and then try to detach-reattach a tab.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 5•2 years ago
|
||
I believe it is this crash:
https://crash-stats.mozilla.org/report/index/26361e9a-e92c-4e52-868c-c77c30221130
Crashes in WR.
Comment 6•2 years ago
|
||
That assert / panic in WR occurs when the caller asks to update an image template for a key that doesn't exist (either never existed, or has been destroyed previously).
The repro steps seem like something that would cause this (perhaps an existing image key that gets deleted and then gecko tries to update it, or perhaps tearing off a tab changes the namespace id of the image key, but gecko doesn't update this where it's used?).
Who knows how image key lifetimes work in Gecko, I wonder?
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•2 years ago
|
Reporter | ||
Comment 9•2 years ago
|
||
Another testcase is : https://www.fxhash.xyz/generative/slug/a-great-space-mind-unfolding
- Open the URL
- Click on "Open" . A new tab will open
- Tear the tab to a new wirndow, and then add it back to the original window.
Tab Crashes
Comment 10•2 years ago
|
||
Emilio, do you know if we have someone well-versed into Webrender-fu that could look at this? The crash volume is relatively low but there's lots of comments in the crash reports, all pointing to the same cause: dragging tabs between windows or out of a window to make a new one. Several comments mention that this happens when dragging the tab between screens. Additionally the crashes seem to occur to people using 3D applications of various kinds (Unity games, 3D viewers, graph viewers), PDFs and YouTube. Here's some example comments:
I tried to move one open tab in a window of multiple tabs (washington post games- scrabble (called something else, but essentially scrabble), to a different window with one tab that was open (youtube), so I could multitask). There was a small, vertical, visual indicator that I successfully did this, so I released the left-click button on my wireless mouse, all open windows (n=2) and all open tabs (n= approx or 5) immediately shut down
I was on a store website and clicked the directions button. The map loaded (or was loading) in a new window, but I wanted it in a tab, so I dragged it to the right side of the tab row of the other window and it crashed.
Moved a tab between 2 windows. The tab had a unity game loading
Firefox crashes regularly when dragging a displayed pdf doc from display B to display A. Reproducable.
Comment 11•2 years ago
|
||
Kelsey / Sotaro / Aosmond come to mind.
Assignee | ||
Comment 12•2 years ago
|
||
I could reproduce the problem. I take the bug.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 14•2 years ago
|
||
The problem happened by ProcessWebRenderParentCommands() handling with invalid transaction message. When a Tab is moved between Windows, WebRenderBridgeParent::UpdateWebRender() is called. It update mApi and mIdNamespace. Then all WebRender related resources are freed. Then a message with old mIdNamespace from WebRenderBridgeChild becomes invalid. Then we should not handle the obsoleted message.
Assignee | ||
Comment 15•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 16•2 years ago
|
||
Hmm, current D170563 causes a lot of failures
https://treeherder.mozilla.org/jobs?repo=try&revision=abd1409fc9d36b05a937d01af74187a0d81745f3
Updated•2 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Description
•