Using object URLs
Jan Honza Odvarko
http://code.google.com/p/fbug/issues/detail?id=4183
Images with .src attribute-value added using
"window.URL.createObjectURL" do not give a preview.
The doc for window.URL.createObjectURL says:
Creates a new object URL, whose lifetime is tied to the document in
the window on which it was created. The new object URL represents the
specified File object.
And my testing says:
the URI doesn't work in another document (except the one it was
created in).
Currently Firebug shows a little tooltip in the HTML panel for IMG
elements and uses the src attribute value to display the element. This
now doesn't work...
Is there any way how to share the URI blob with another document? I
guess it's not possible to get the File object from the URI and call
the createObjectURL again to get different and working URI, correct?
Any hints how to solve this?
Thanks!
Honza
Boris Zbarsky
> And my testing says:
> the URI doesn't work in another document (except the one it was
> created in).
It should, if they're same-origin. Are they?
-Boris
Kyle Huey
would expect this to "just work".
- Kyle
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Jan Honza Odvarko
that is loaded using <browser> element. The <browser> element doesn't
specify type and so uses: chrome (default behaviour): A browser,
intended to be used for loading privileged content using a chrome://
All the HTML is consequently injected into that page as necessary.
The loaded HTML page can be seen here:
http://code.google.com/p/fbug/source/browse/branches/firebug1.7/content/firebug/panel.html
The XUL <browser> code is here:
http://code.google.com/p/fbug/source/browse/branches/firebug1.7/content/firebug/firebugOverlay.xul#385
So, my feeling is yes, it should have access to privileged content
(however not sure if through moz-datafile)
Honza
Kyle Huey
onload handler of the <img>, ensuring that the object URL is gone by the
time Firebug tries to preview the image. If that call is commented out,
everything works as expected.
One might say that we should hold on to object URLs beyond the revoke call
in some way that makes them accessible only to chrome, but I don't think
that's worth the extra complexity here.
- Kyle
On Mon, Mar 7, 2011 at 8:17 AM, Jan Honza Odvarko <odv...@gmail.com> wrote:
Jan Honza Odvarko
> The testcase given is bogus. It calls window.URL.revokeObjectURL from the
> onload handler of the <img>, ensuring that the object URL is gone by the
> time Firebug tries to preview the image. If that call is commented out,
> everything works as expected.
>
> One might say that we should hold on to object URLs beyond the revoke call
> in some way that makes them accessible only to chrome, but I don't think
> that's worth the extra complexity here.
>
> - Kyle
>
>
> > This problem has been originally reported for Firebug here:
> >http://code.google.com/p/fbug/issues/detail?id=4183
>
> > Images with .src attribute-value added using
> > "window.URL.createObjectURL" do not give a preview.
>
> > The doc for window.URL.createObjectURL says:
> > Creates a new object URL, whose lifetime is tied to the document in
> > the window on which it was created. The new object URL represents the
> > specified File object.
>
> > And my testing says:
> > the URI doesn't work in another document (except the one it was
> > created in).
>
> > Currently Firebug shows a little tooltip in the HTML panel for IMG
> > elements and uses the src attribute value to display the element. This
> > now doesn't work...
>
> > Is there any way how to share the URI blob with another document? I
> > guess it's not possible to get the File object from the URI and call
> > the createObjectURL again to get different and working URI, correct?
>
> > Any hints how to solve this?
>
> > Thanks!
> > Honza
>
> > _______________________________________________
> > dev-platform mailing list
> >https://lists.mozilla.org/listinfo/dev-platform
>
>
Thanks for the analysis Kyle!
Honza