Closed
Bug 718857
Opened 12 years ago
Closed 12 years ago
Entering document.body.innerHTML into the Web Console (GCLI) fails and throws exception
Categories
(DevTools :: Console, defect, P1)
DevTools
Console
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 12
People
(Reporter: fryn, Unassigned)
References
Details
Steps to reproduce: 1. Open Web Console. 2. Type {document.body.innerHTML into it. 3. Press enter. Expected result: The DOM is serialized as a string and outputted. Actual result: An exception is thrown and outputted. This only applies to branches 12 and up. The previous (unintended) behavior of the Web Console (in the 10 and 11 branches) was to hang the entire browser upon document.body.innerHTML being entered.
Comment 1•12 years ago
|
||
This is happening because we're looking at the exported HTML in an XML context. (the error in the error consile is 'Error undefined entity '. There *could* be security implications of this. CCing Tanvi.
Priority: -- → P1
Summary: Entering document.body.innerHTML into the Web Console fails and throws exception → Entering document.body.innerHTML into the Web Console (GCLI) fails and throws exception
Comment 2•12 years ago
|
||
Using Firefox 9.0.1, I get the DOM serialized as a string. Using Nightly, I get the actual HTML displayed in the webconsole (the DOM doesn't appear to be serialized). What privileges does the Web Console have? Is it restricted to only take actions on the DOM tree in the current document? Will investigate some more.
Comment 3•12 years ago
|
||
https://wiki.mozilla.org/Security/Reviews/Firefox4/Web_Console_Security_Review "We assume that the execution in sandbox will only be able to access the current contentWindow's scope."
Comment 4•12 years ago
|
||
Joe, if the exported HTML is in an XML context, why does it display the HTML as if it was an HTML context? Perhaps we can discuss when you get back.
Comment 5•12 years ago
|
||
Here's what should happen:
> { document.body.innerHTML }
GCLI recognizes this is a JavaScript command, so it evals it (in a sandbox) and gets a long string of HTML, which is a serialization of the content document.
It then attempts to display this long string to the user. To do this it has to add this string to the chrome document. This should be initially worrying in that we're adding page content to a chrome privileged document, however we're serializing it to a string first, so this should be safe.
However the error message comes from an attempt to parse the HTML in an XML content (hence the error) which indicates that we are doing the addition in an unsafe way.
I have a patch waiting in review which may well fix this, otherwise I'll be fixing it just as soon as I'm back.
Comment 6•12 years ago
|
||
I've looked further - I believe that bug 693269 has the fix for this. Dave, could you review it? And maybe even land it - it's been through try. There could be security implications.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•