Bug 97095 – MediaStream API: Extend UserMediaRequest with a ownerDocument method

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Tommy Widenflycht]

Chromium need to know exactly which frame called getUserMedia so that it can clean away the stream when the frame goes away. Since that information is available in webkit add an accessor method.

[Tommy Widenflycht]

Created attachment 164717 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[Adam Barth]

Comment on attachment 164717 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=164717&action=review

> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:77
> +    return ((Document*)m_scriptExecutionContext)->frame();

We use C++ style casts:

static_cast<Document*>(m_scriptExecutionContext)->frame()

[Adam Barth]

Comment on attachment 164717 [details]
Patch

This is fine, but it should return the associated Document rather than the Frame.  DOM-related objects are associated with Documents (the "D" in DOM stands for Document).  View-related objects are associated with Frames.

WebDocument has a frame() function, so the embedder can find the Frame if it needs that for its own purposes.

[Adam Barth]

Also "calling" isn't the right name.  That's a scripting related concept and there's no reason these objects are necessarily products of script calls.  Maybe the term "ownerDocument" is better?

[Adam Barth]

Also, keep in mind that m_scriptExecutionContext can be 0 since this object doesn't keep the Document alive.

[Tommy Widenflycht]

Created attachment 164871 [details]
Patch

[Tommy Widenflycht]

Comment on attachment 164717 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=164717&action=review

>> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:77
>> +    return ((Document*)m_scriptExecutionContext)->frame();
> 
> We use C++ style casts:
> 
> static_cast<Document*>(m_scriptExecutionContext)->frame()

Fixed.

[Tommy Widenflycht]

(In reply to comment #4)
> (From update of attachment 164717 [details])
> This is fine, but it should return the associated Document rather than the Frame.  DOM-related objects are associated with Documents (the "D" in DOM stands for Document).  View-related objects are associated with Frames.
> 
> WebDocument has a frame() function, so the embedder can find the Frame if it needs that for its own purposes.

Much nicer, thanks!

[Tommy Widenflycht]

(In reply to comment #5)
> Also "calling" isn't the right name.  That's a scripting related concept and there's no reason these objects are necessarily products of script calls.  Maybe the term "ownerDocument" is better?

I'm not arguing with you but these calls are only called as a direct response to a JS call. However that is ownerDocument is much better.

[Tommy Widenflycht]

(In reply to comment #6)
> Also, keep in mind that m_scriptExecutionContext can be 0 since this object doesn't keep the Document alive.

Fixed.

[Adam Barth]

Comment on attachment 164871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=164871&action=review

> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:80
> +    if (m_scriptExecutionContext) {
> +        ASSERT(m_scriptExecutionContext->isDocument());
> +        return static_cast<Document*>(m_scriptExecutionContext);
> +    }
> +
> +    return 0;

The other way you could have done this, by the way, is:
ASSERT(isMainThread());
return static_cast<Document*>(m_scriptExecutionContext);

But this is fine too.

[WebKit Review Bot]

Comment on attachment 164871 [details]
Patch

Clearing flags on attachment: 164871

Committed r129145: <http://trac.webkit.org/changeset/129145>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.