Technically there was a time/way to tell gecko not to support frames.
There was a time when i played w/ that support while we were
spidering. Browser.frames.enabled / default / boolean / true.
It seems to work as of a nightly from aug 13 (iirc it requires a
restart. I'd suggest using a distinct
João Eiras wrote:
On , Jonas Sicking [EMAIL PROTECTED] wrote:
(...)
Here is the list of elements that we *don't* execute scripts inside of
in firefox:
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148
i.e. iframe, noframes, noembed
Everywhere else
On Thu, 21 Aug 2008 23:54:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Here is the list of elements that we *don't* execute scripts inside of
in firefox:
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148
i.e. iframe, noframes, noembed
Everywhere
Simon Pieters wrote:
On Thu, 21 Aug 2008 23:54:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Here is the list of elements that we *don't* execute scripts inside of
in firefox:
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148
i.e. iframe, noframes,
: WHATWG Mailing List
Subject: Re: [whatwg] Fallback behavior
On Tue, 13 Mar 2007, Anne van Kesteren wrote:
Not sure. Should
object data=foo
img src=bar onload=alert('x')
show a modal dialog?
Yes.
On Tue, 13 Mar 2007, Mihai Sucan wrote:
No, it should not.
It's too late to change
On Wed, 20 Aug 2008, Křištof Želechovski wrote:
I am not sure what Ian means. M.S.'s description at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/010043.html
he seems to be opposing is definitive, exhaustive and that is what
Internet Explorer 7 does. Scripts attached to
On Mon, 12 Mar 2007, Maciej Stachowiak wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with fallback
content when not falling back?
In theory, this is now defined for all element combinations. Please
Maciej Stachowiak wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with fallback
content when not falling back?
Presumably it should be parsed into the DOM, but should not render -
that's the de facto
On Tue, 13 Mar 2007 00:47:23 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with fallback
content when not falling back?
Presumably it should be parsed into
On Mar 13, 2007, at 1:46 AM, Anne van Kesteren wrote:
On Tue, 13 Mar 2007 00:47:23 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
As far as I can tell, the current spec does not adequately define
how fallback behavior works. Specifically, what should be done
with fallback content when
On Tue, 13 Mar 2007 11:28:36 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with
fallback content when not falling back?
Presumably it should be parsed into
Le Tue, 13 Mar 2007 13:21:14 +0200, Anne van Kesteren [EMAIL PROTECTED] a
écrit:
Not sure. Should
object data=foo
img src=bar onload=alert('x')
show a modal dialog?
No, it should not. Fallback content should not execute (styling and
scripts), also, fallback content should not be
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with
fallback content when not falling back?
Presumably it should be parsed into the DOM, but should not render -
that's the de facto behavior. But I don't
On 3/12/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
object data=about:blank
bfallback/b
script
alert('y');
/script
/object
I asked about this a while ago. Here's the old discussion:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-May/006365.html
14 matches
Mail list logo
