830076 - <noscript>-content is not rendered in sandboxed iframe

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect, P5)

Description

[Patrick]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Presumably we need to tell the parser script is disabled.  Ian, Henri?

Comment 2

[Henri Sivonen (:hsivonen)]

(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

[Ian Melven :imelven]

(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.

Comment 4

[Patrick]

https://bugs.webkit.org/show_bug.cgi?id=36092

Comment 6

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 7

[Anne (:annevk)]

It seems this got fixed at some point: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8931.