Summary: | REGRESSION (r258977): Crash under Document::visibilityStateChanged | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||
Component: | Media | Assignee: | Chris Dumez <cdumez> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | esprehn+autocc, ews-watchlist, kangil.han, webkit-bug-importer, youennf | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 208516 | ||||||
Attachments: |
|
Description
Chris Dumez
2020-04-15 10:24:24 PDT
Created attachment 396546 [details]
Patch
I am not quite sure how to write a test for this yet. If anybody has an idea, please let me know. (In reply to Chris Dumez from comment #2) > I am not quite sure how to write a test for this yet. If anybody has an > idea, please let me know. Looks like there is an internals.setPageVisibility() method. I will try that we a detached iframe document to see if it reproduces. Some JS event must get fired synchronously when Document::visibilityStateChanged() is called. The "visibilitychange" is fired asynchronously so I wasn't able to write a test based on this event. I believe a JS event (likely media related) gets fired synchronously and the event handler in JS removes one of the iframes from the document. Could it be the muted event of a MediaStreamTrack? On iOS, if document goes in the background, a video capture track gets muted. (In reply to youenn fablet from comment #5) > Could it be the muted event of a MediaStreamTrack? > On iOS, if document goes in the background, a video capture track gets muted. Nope, since this would happen after the setCapturePageState call. (In reply to youenn fablet from comment #6) > (In reply to youenn fablet from comment #5) > > Could it be the muted event of a MediaStreamTrack? > > On iOS, if document goes in the background, a video capture track gets muted. > > Nope, since this would happen after the setCapturePageState call. I don't think the order matters. Page::forEachDocument() gathers all the documents of the page in a Vector. Then iterates over this vector and calls Document::visibilityStateChanged() on each document. The first document is the top document. So if the top document has an event listener for any event that gets called synchronously during Document::visibilityStateChanged() and if that event listener removes a subframe from the document then we would hit this crash when calling Document::visibilityStateChanged() for the subframe document. (In reply to Chris Dumez from comment #7) > (In reply to youenn fablet from comment #6) > > (In reply to youenn fablet from comment #5) > > > Could it be the muted event of a MediaStreamTrack? > > > On iOS, if document goes in the background, a video capture track gets muted. > > > > Nope, since this would happen after the setCapturePageState call. > > I don't think the order matters. Page::forEachDocument() gathers all the > documents of the page in a Vector. Then iterates over this vector and calls > Document::visibilityStateChanged() on each document. The first document is > the top document. > > So if the top document has an event listener for any event that gets called > synchronously during Document::visibilityStateChanged() and if that event > listener removes a subframe from the document then we would hit this crash > when calling Document::visibilityStateChanged() for the subframe document. HTMLMediaElement::visibilityStateChanged() gets called. Any idea if this can fire an event synchronously? Committed r260142: <https://trac.webkit.org/changeset/260142> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396546 [details]. |