On Wed, 9 Feb 2011, Boris Zbarsky wrote:
On 2/9/11 10:12 PM, Ian Hickson 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
On 6/6/11 4:45 PM, Ian Hickson wrote:
data:text/html,body onload=alert(window[0].location)iframe
src=javascript:''
Woah, funky. (Gecko thinks the location is javascript:''.)
Well... it sort of is. ;)
It's defined; see the section on theonject element.
I've read that section, in
On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Feb 2011, Philip Jägenstedt wrote:
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
On Mon, 14 Feb 2011, Philip Jägenstedt wrote:
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
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
On 2/10/2011 12:09 PM, whatwg-requ...@lists.whatwg.org wrote:
Date: Thu, 10 Feb 2011 13:43:11 -0500
From: Boris Zbarskybzbar...@mit.edu
To: Adam Barthw...@adambarth.com
On 2/10/11 1:38 PM, Adam Barth wrote:
The connection is that these features are unlikely to get implemented
in WebKit
On Fri, Feb 11, 2011 at 2:20 PM, Charles Pritchard ch...@jumis.com wrote:
On 2/10/2011 12:09 PM, whatwg-requ...@lists.whatwg.org wrote:
Date: Thu, 10 Feb 2011 13:43:11 -0500
From: Boris Zbarskybzbar...@mit.edu
To: Adam Barthw...@adambarth.com
On 2/10/11 1:38 PM, Adam Barth wrote:
The
Apologies for not reading the whole thread before replying, but the
design Darin describes below has worked well in WebKit thus far. I'd
be hesitant to make JavaScript URLs work in more contexts due to the
risk of introducing security vulnerabilities into the engine.
Adam
On Tue, Nov 30, 2010
On Thu, Feb 10, 2011 at 6:29 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/10/11 4:36 AM, Adam Barth wrote:
Apologies for not reading the whole thread before replying, but the
design Darin describes below has worked well in WebKit thus far. I'd
be hesitant to make JavaScript URLs work in
On 2/10/11 1:38 PM, Adam Barth wrote:
The connection is that these features are unlikely to get implemented
in WebKit anytime soon. To the extent that we want the spec to
reflect interoperable behavior across browsers, speccing things that
aren't (and aren't likely to become) interoperable is a
On Thu, Feb 10, 2011 at 10:43 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/10/11 1:38 PM, Adam Barth wrote:
The connection is that these features are unlikely to get implemented
in WebKit anytime soon. To the extent that we want the spec to
reflect interoperable behavior across browsers,
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
On 2/9/11 10:12 PM, Ian Hickson 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:
On Wed, Aug 11, 2010 at 7:58 PM, Cris Neckar c...@chromium.org wrote:
Browsers currently deal with these in a fairly ad-hoc way. I used the
following to test a few examples in various browsers.
embed src=javascript:alert('embed-src');/embed
embed src=http://none;
On Thu, 02 Dec 2010 23:56:33 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/2/10 2:31 PM, Daniel Veditz wrote:
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
I dunno about solid, but the obvious things you can do with
javascript: that you can't do as
On Wed, 01 Dec 2010 16:24:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/1/10 3:16 AM, Philip Jägenstedt wrote:
Do you do that just for inlines, or also when navigating to javascript:
URLs? If it's both, then that's something we'd need to standardize,
unless all browsers already do the
On Thu, 02 Dec 2010 11:38:33 +0100, Simon Pieters sim...@opera.com wrote:
On Thu, 02 Dec 2010 09:32:43 +0100, Philip Jägenstedt
phil...@opera.com wrote:
Right, these aren't inlines, in Opera terminology at least. As far as
I
can see the spec agrees on this, as frames/iframes have their
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
I dunno about solid, but the obvious things you can do with
javascript: that you can't do as easily with data: are things
that are dynamic. That said, in a sandbox the only things that
are available as
On 12/2/10 2:31 PM, Daniel Veditz wrote:
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
I dunno about solid, but the obvious things you can do with
javascript: that you can't do as easily with data: are things
that are dynamic. That said, in a sandbox the
On 12/2/10 4:26 PM, Daniel Veditz wrote:
On 12/1/10 10:25 AM, timeless wrote:
Pnglets date to around 1999 according to a quick read of http://elf.org/pnglets/
Pnglets haven't worked in Mozilla for a long time,img src= is
sandboxed.
It's not just sandboxed; it also doesn't execute.
On Tue, 30 Nov 2010 20:30:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/30/10 4:35 AM, Philip Jägenstedt wrote:
No, as far as I know, Opera hasn't ever sandboxed any inline javascript:
URL execution.
So img src=javascript: runs the JS in the page's context in Opera?
No, img was on
On Tue, 30 Nov 2010 22:51:28 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/30/10 2:37 PM, Darin Adler wrote:
In WebKit, we have treated the javascript URL scheme as a special case,
with explicit code in the loader, and not handled by general purpose
resource protocol machinery. Maciej
On 12/1/10 3:16 AM, Philip Jägenstedt wrote:
No, img was on the list of inlines where javascript: URL execution was
explicitly blocked.
Ah, ok. Gotcha.
Someone who manages to install a working Java plugin might want to test
this. It doesn't seem like it could be a compat issue to me.
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
Given that the feature can't be made completely consistent for security
reasons, I guess it comes down to use cases. Are there solid use cases
for using the return values of sandboxed scripts as the content of
documents, that aren't equally well
On Wed, Dec 1, 2010 at 5:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Oh, the other thing that JavaScript can do that data: can't do is trade off
url length for CPU time. A data: URI to write out the first 3000 Fibonacci
numbers would be a lot longer than the equivalent javascript: URI.
On Wed, 01 Dec 2010 19:11:25 +0100, timeless timel...@gmail.com wrote:
On Wed, Dec 1, 2010 at 5:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Oh, the other thing that JavaScript can do that data: can't do is trade
off url length for CPU time. A data: URI to write out the first 3000
Fibonacci
On Wed, Dec 1, 2010 at 8:18 PM, Anne van Kesteren ann...@opera.com wrote:
These can also be done with data:text/html,script.../script and maybe
canvas. It is slightly longer, but not much.
Sure, play the canvas card. I could just as easily respond to
everything by saying you don't need layout
On Mon, 29 Nov 2010 16:36:32 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/25/10 9:10 AM, 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
On Tue, Nov 30, 2010 at 11:35 AM, Philip Jägenstedt phil...@opera.com wrote:
Also, note that embed src=javascript: and applet
something=javascript: (can't recall the attr name right now) also execute
the script in Firefox. Do they in Opera?
Neither of these execute in Opera, both were
http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html
actually, potentially each of these are probably potential candidates
for something:
CODEBASE
ARCHIVE
OBJECT
On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote:
http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html
actually, potentially each of these are probably potential candidates
for something:
CODEBASE
ARCHIVE
OBJECT
None of those worked for me, even with the
On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt phil...@opera.com
wrote:
On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote:
http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html
actually, potentially each of these are probably potential candidates
On Tue, Nov 30, 2010 at 3:21 PM, Simon Pieters sim...@opera.com wrote:
How about code= (or param name=code value=javascript:)?
i'm assuming not, the spec claims it's not allowed to take an absolute url.
On Tue, 30 Nov 2010 14:21:21 +0100, Simon Pieters sim...@opera.com wrote:
On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt
phil...@opera.com wrote:
On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote:
On 11/30/10 4:35 AM, Philip Jägenstedt wrote:
No, as far as I know, Opera hasn't ever sandboxed any inline javascript:
URL execution.
So img src=javascript: runs the JS in the page's context in Opera?
Also, note that embed src=javascript: and applet
something=javascript: (can't recall the
On 11/30/10 4:35 AM, Philip Jägenstedt wrote:
So far, it seems that the fastest way to reach compat between browsers
is to simply not run inline javascript: URLs.
One other thing since this is a generic protocol, if we define
special-case behavior for it in some cases (e.g. img), that
In WebKit, we have treated the javascript URL scheme as a special case, with
explicit code in the loader, and not handled by general purpose resource
protocol machinery. Maciej Stachowiak suggested this approach, back in 2002,
and one of the reasons he gave me at the time is that thought WebKit
On 11/30/10 2:37 PM, Darin Adler wrote:
In WebKit, we have treated the javascript URL scheme as a special case, with
explicit code in the loader, and not handled by general purpose resource
protocol machinery. Maciej Stachowiak suggested this approach, back in 2002,
and one of the reasons he
On 11/25/10 9:10 AM, 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
On Tue, 16 Nov 2010 02:15:45 +0100, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Aug 2010, Boris Zbarsky wrote:
For what it's worth, as I see it there are three possible behaviors for
a javascript: URI (whether in an attribute value or elsewhere):
1) Don't run the script.
2) Run the script,
On Wed, 11 Aug 2010, Cris Neckar wrote:
The HTML5 Spec is somewhat ambiguous on the handling of javascript: URLs
when supplied as attributes to different elements. It does not
specifically prohibit handling them in most cases but I was wondering if
this has been discussed and whether
On 11/15/10 8:15 PM, Ian Hickson wrote:
Gecko's currently-intended behavior is to do what section 6.1.5
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
On 8/11/10 2:57 PM, Cris Neckar wrote:
6.1.5
So for example a javascript: URL for a src attribute of an img
element would be evaluated in the context of an empty object as soon
as the attribute is set; it would then be sniffed to determine the
image type and decoded as an image.
Right.
43 matches
Mail list logo
