W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] Fallback behavior

From: timeless <timeless@gmail.com>
Date: Tue, 26 Aug 2008 02:18:24 +0300
Message-ID: <26b395e60808251618k462b3acfoe7a2cf26bce1455f@mail.gmail.com>
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 profile). I think i remember
hitting the script issue in testing, but as it wasn't a primary task
we didn't push to fix it. It should be fixed, but i'd understand
someone asking for tests....

On 8/22/08, Jonas Sicking <jonas at sicking.cc> wrote:
> Jo?o Eiras wrote:
>> On , Jonas Sicking <jonas at sicking.cc> 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 we do execute the script.
>>>
>>> The reason these elements ended up at the list is in bugs
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=5847
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=26669
>>>
>>> / Jonas
>>
>>
>> I kind of agree with iframe and noembed, but noframes ?
>> noframes, IMO, it fairly legitimate, because you can have scripts
>> providing fallback, or redirecting to another page.
>
> Yes, we would presumably run scripts in <noframes> if we didn't have
> frame support. There is even a comment in the code that says that we
> should not check for noscript if we ever add the ability to turn off
> frame support.
>
> / Jonas
>

-- 
Sent from Gmail for mobile | mobile.google.com
Received on Monday, 25 August 2008 16:18:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:04 UTC