Bug 210555 – REGRESSION (r258977): Crash under Document::visibilityStateChanged

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Chris Dumez]

Crash under Document::visibilityStateChanged:
[  0] 0x0000000107974669 WebCore`WebCore::Document::visibilityStateChanged() + 409 at Document.cpp:1749
       1745	        client->visibilityStateChanged();
       1746	
       1747	#if ENABLE(MEDIA_STREAM)
       1748	    if (hidden()) {
    -> 1749	        RealtimeMediaSourceCenter::singleton().setCapturePageState(hidden(), page()->isMediaCaptureMuted());
       1750	        return;
       1751	    }
       1752	#if PLATFORM(IOS_FAMILY)
       1753	    if (!PlatformMediaSessionManager::sharedManager().isInterrupted())

[Chris Dumez]

Created attachment 396546 [details]
Patch

[Chris Dumez]

I am not quite sure how to write a test for this yet. If anybody has an idea, please let me know.

[Chris Dumez]

(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.

[Chris Dumez]

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.

[youenn fablet]

Could it be the muted event of a MediaStreamTrack?
On iOS, if document goes in the background, a video capture track gets muted.

[youenn fablet]

(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.

[Chris Dumez]

(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.

[Chris Dumez]

(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?

[EWS]

Committed r260142: <https://trac.webkit.org/changeset/260142>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 396546 [details].

[Radar WebKit Bug Importer]

<rdar://problem/61840165>