ian at hixie.ch
Wed Feb 9 19:12:09 PST 2011
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:
> > >
> > 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
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
For <embed>, only Firefox does this (tested using window.alert). I didn't
test further with <embed> since there doesn't seem to be a use case for
I didn't test <applet>.
> Note that there is some confusion here in terms of browsing contexts and
> <object>, since <object> does expose a Document object sometimes (but not
> others) and does participate in session history sometimes, I believe... So
> I'm not quite sure what behavior the spec calls for for <object>.
It's defined; see the section on the <onject> element.
> > > For what it's worth, as I see it there are three possible behaviors for
> > >
> > > 1) Don't run the script.
> > > 2) Run the script, but in a sandbox.
> > > 3) Run the script against some Window object (which one?)
> > >
> > > Defining which of these happens in which case would be good.
> > > Again, Gecko's behavior is #2 by default (in all sorts of
> > > situations; basically anywhere you can dereference a URI), with
> > > exceptions made to do #3 in some cases.
> > That's what the spec says currently.
> That doesn't agree with your comments about <script src> above...
Indeed, I misspoke. The spec actually defaults to not running the script,
but in most circumstances of interest does #2, and in a number of other
cases does #3 or does #1 explicitly even if it would otherwise do #2 or
#3. It's complicated. :-)
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
> be the simplest to implement and the fastest way to reach
> in more contexts, which, even if sandboxed, doesn't seem particularly
URLs to generate bitmaps, and I don't really see any harm with this.
> 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.
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.
On Tue, 30 Nov 2010, Boris Zbarsky wrote:
> At least in Gecko, the return value string is examined to see whether
> all the charcode values are < 255. If they are, then the string is
> converted to a byte array by just dropping the high byte of every char.
> So you can pretty easily generate image data this way.
> If any of the bytes are > 255, then the string is encoded as UTF-8
Hm. This currently isn't specced; the spec just assumes the return value
is text/html string data and doesn't say what encoding to use. Is there a
good way to test this in the context of an <iframe>, where all the
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg