Last Comment Bug 718857 - Entering document.body.innerHTML into the Web Console (GCLI) fails and throws exception
: Entering document.body.innerHTML into the Web Console (GCLI) fails and throws...
Product: Firefox
Classification: Client Software
Component: Developer Tools: Console (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: Firefox 12
Assigned To: Nobody; OK to take it and work on it
: Brian Grinstead [:bgrins]
: 698895 (view as bug list)
Depends on: 701711
  Show dependency treegraph
Reported: 2012-01-17 15:36 PST by Frank Yan (:fryn)
Modified: 2012-01-28 13:31 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Frank Yan (:fryn) 2012-01-17 15:36:25 PST
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] (needinfo me or ping on irc) 2012-01-18 22:40:40 PST
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] 2012-01-19 14:21:31 PST
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] 2012-01-19 14:34:33 PST

"We assume that the execution in sandbox will only be able to access the current contentWindow's scope."
Comment 4 Tanvi Vyas [:tanvi] 2012-01-19 15:15:02 PST
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] (needinfo me or ping on irc) 2012-01-19 21:54:17 PST
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] (needinfo me or ping on irc) 2012-01-19 22:02:41 PST
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.
Comment 7 Joe Walker [:jwalker] (needinfo me or ping on irc) 2012-01-24 02:50:22 PST
*** Bug 698895 has been marked as a duplicate of this bug. ***
Comment 8 Michael Ratcliffe [:miker] [:mratcliffe] 2012-01-25 08:59:56 PST
*** Bug 720184 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.