718857 - Entering document.body.innerHTML into the Web Console (GCLI) fails and throws exception

Status: RESOLVED FIXED

(DevTools :: Console, defect, P1)

Description

[Frank Yan (:fryn)]

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

[Joe Walker [:jwalker]]

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.

Comment 2

[Tanvi Vyas[:tanvi]]

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

[Tanvi Vyas[:tanvi]]

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

[Tanvi Vyas[:tanvi]]

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

[Joe Walker [:jwalker]]

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

[Joe Walker [:jwalker]]

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.