<noscript>-content is not rendered in sandboxed iframe

UNCONFIRMED
Unassigned

Status

()

Core
DOM: Core & HTML
UNCONFIRMED
5 years ago
3 years ago

People

(Reporter: Patrick, Unassigned)

Tracking

20 Branch
x86_64
Windows 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20130111 Firefox/20.0
Build ID: 20130111042017

Steps to reproduce:

Open a website where an iframe with sandbox attribute includes another site which has a <noscript> tag.
I've seen this in Aurora 20.0a2, but i've not tested it in other Firefox versions yet.

IE10 and Chrome 24.0.1312.52 are not showing the plain text of a <noscript>-tag.


Actual results:

The content of the <noscript> tag is showed in plain text.


Expected results:

The content of the <noscript> tag should be rendered the same way as javascript were disabled.

Updated

5 years ago
Component: Layout: HTML Frames → DOM: Core & HTML
Presumably we need to tell the parser script is disabled.  Ian, Henri?
(In reply to Boris Zbarsky (:bz) from comment #1)
> Presumably we need to tell the parser script is disabled.  Ian, Henri?

In the normal case, the parser takes care of this itself:
http://mxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5StreamParser.cpp#872
http://mxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5TreeOpExecutor.cpp#683

However, there is precedent for the state seeing by the parser and the state seen by the code that generates the UA style sheet rule for noscript getting out of sync:
bug 662907.

Does the sandbox attribute do its thing before or after the presshell creation?

Comment 3

5 years ago
(In reply to Henri Sivonen (:hsivonen) from comment #2)
>
> Does the sandbox attribute do its thing before or after the presshell
> creation?

The sandbox flags are set on the document during StartDocumentLoad and are set on a new iframe when the frame loader is about to start loading the document for the frame - I looked through the documentation I could find but I'm not sure if this is before or after presshell creation.

Note that disabling scripts for a sandboxed document doesn't disable Javascript on the docshell using nsDocShell::SetAllowJavascript(false) but instead uses the same script execution choke points as CSP - this is because turning off scripts for the docshell broke e.g. controls for the <video> element. 

Looking at the code Henri linked to, it seems like we could add a check to see if the document has the sandboxed scripts flag to nsHtml5TreeOpExecutor::IsScriptEnabled() or the function it calls : nsContentUtils::GetSecurityManager()->CanExecuteScripts(cx, mDocument->NodePrincipal(), &enabled);

It's interesting that the other browsers that have implemented iframe sandbox also don't render <noscript> in this case and I wonder if that was a deliberate choice for some reason. I don't *think* the intention of iframe sandbox is to have a sandboxed document not be able to tell it's sandboxed, which would be one argument for not rendering <noscript>. As far as the WHATWG HTML spec goes, all I could find was this passage "If scripting is disabled for browsing context passed to this algorithm, then abort these steps, as if the script did nothing but return void." which is not specific to iframe sandbox.

Updated

3 years ago
Duplicate of this bug: 1028920
You need to log in before you can comment on or make changes to this bug.