[Webkit-unassigned] [Bug 74386] Migrate createObjectURL & revokeObjectURL to static (Class) methods

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=74386





--- Comment #9 from Erik Arvidsson <arv at chromium.org>  2011-12-21 14:02:17 PST ---
(In reply to comment #8)
> (From update of attachment 119207 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=119207&action=review
> 
> I'm going to mark this R+, but there is one subtle issue (mentioned below) that you might want to consider before landing this patch.
> 
> > Source/WebCore/html/DOMURL.cpp:88
> > +static PublicURLManagerMap& publicURLManagerMap()
> 
> Interesting design choice.  Another option is to store the information in the ScriptExecutionContext as some sort of a mix-in.  We don't have a facility for doing that at the moment, but there are a bunch of cases like this where it would be useful.
> 
> > Source/WebCore/html/DOMURL.idl:34
> > -        [ConvertNullStringTo=Undefined] DOMString createObjectURL(in MediaStream stream);
> > +        static [ConvertNullStringTo=Undefined,CallWith=ScriptExecutionContext] DOMString createObjectURL(in MediaStream stream);
> 
> So, this is actually slightly different because you'll get a different ScriptExecution context.  After this change, you get the script execution context associated with the currently executing script rather than the one associated with the window object that contains this object.  Is that an intentional change?  If so, should we add a test that demonstrates it?

Good catch. That is the wrong behavior. If you do "someWindow.URL.createObjectURL(...)" that URL should be associated with the ScriptExecution context of "someWindow".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.