On Thu, 10 Feb 2011 04:12:09 +0100, Ian Hickson <i...@hixie.ch> wrote:
On Mon, 15 Nov 2010, Boris Zbarsky wrote:
On 11/15/10 8:15 PM, Ian Hickson wrote:
> > Gecko's currently-intended behavior is to do what [the spec]
> > describes in all cases except:
> >
> > <iframe src="javascript:">
> > <object data="javascript:">
> > <embed src="javascript:">
> > <applet code="javascript:">
>
> What does it do for those cases if it doesn't match the spec?
For <iframe> the behavior in Gecko currently is different in terms of
what the URI of the result document of javascript: is set to.
How does it differ? As far as I can tell, it works the same as the spec
says (the document.location is "about:blank" in the example above).
For the others, I believe we execute them in the script environment of
the
owner document of the object/embed/applet, whereas the spec requires
them to
execute in a sandbox, as far as I can tell.
Ah, interesting. For <object>, this seems to be a unique feature of
Firefox. Opera also executes the script in the context of the owner, but
then ignores the results as far as I can tell. Other browsers don't seem
to support javascript: in data="" at all.
For the record, I removed Opera's "support" (I assume it was an unintended
side-effect) for <object data="javascript:..."> along with the rest at the
time when I wrote my previous mail in this thread. This intentionally
doesn't match what the spec says. (Disclaimer: this is only my opinion on
something that isn't really my area of expertise, so others at Opera might
decide that the spec is great and push in the opposite direction. It seems
unlikely at this point, though.)
On Thu, 25 Nov 2010, Philip Jägenstedt wrote:
Based on this, unless there are corner-cases I've missed, it seems
unlikely that there's a large body of web content that depends on inline
javascript: URLs executing. My current plan is to try completely
blocking javascript: URLs in the contexts mentioned above. This seems to
be the simplest to implement and the fastest way to reach
interoperability. The alternative is to start executing javascript: URLs
in more contexts, which, even if sandboxed, doesn't seem particularly
useful.
There's a minor body of work on the Web that is based on using
javascript:
URLs to generate bitmaps, and I don't really see any harm with this.
Even if there's no harm, it's unneeded complexity that so far doesn't seem
to be needed for web compat, since it currently would only work in Firefox.
I'll keep you posted if there are any compatibility issues that come up
with this. Assuming (boldly) there is not, would there be support from
other browsers to move in this direction and change the spec to match?
What the spec currently specs seems to be a reasonable compromise between
security, compatibility needs based on what browsers do today, use cases,
and consistency across the platform (usability), in that order.
What compatibility needs? The only thing I'm aware of is using <img
src="javascript:..."> to generate X BitMap images.[1][2] However, the
examples would break if the execution was sandboxed as per the spec.
Obviously if browsers implement something different, then I'll happily
move the spec to match, but it would be sad to just close off these
features without good reason.
Of what has been brought up so far, javascript: as an inline resource is
not very useful at all, so IMO the only reason to keep it would be for
legacy compat. I'll follow up on this again once the change to block
inline javascript: URLs in Opera has been in the wild for a while,
hopefully reporting that no compat issues have arisen.
[1]
http://www.ridgway.co.za/archive/2005/11/13/dynamicjavascriptimagegenerationwithxbmimages.aspx
[2] http://david.blackledge.com/XBMDrawLibrary.html
--
Philip Jägenstedt
Core Developer
Opera Software
