Document from DOMParser or XHR with responseType="document" breaking debugging functionality.




Developer Tools: Console
4 years ago
2 years ago


(Reporter: rielz, Unassigned)


29 Branch

Firefox Tracking Flags

(Not tracked)





4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

Running this Javascript code, after DOMContentLoaded and served from a webserver, observing with the developer tools:

var parser = new DOMParser();
var doc = parser.parseFromString("<html><head></head><body></body></html>", "text/html");




Actual results:

For "console.dir(doc);" nothing is displayed in the console. (Not even an error.)
For "console.dir(doc.body);" the text "<body>" is shown but the box underneath is empty, no properties are visible.

The "debugger;" statement is ignored, also manual breakpoints in the debug view are ignored.

The string "done" is displayed correctly even if above breakpoints are ignored.

Expected results:

The first call to console.dir should display the HTMLDocument and all its properties that are available, like a normal "console.dir(document);" does and should not display nothing at all.

The second call to console.dir should include all properties of the body of the parsed Document.

The debugger of the developer tools should break at the debugger statement and also manual breakpoints should be available in order to inspect the "doc" variable.
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
System JS : ERROR resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/utils.js:206 - TypeError: aSourceURL is undefined

The stack to that point seems to be:

0 WCU_abbreviateSourceURL(aSourceURL = undefined, aOptions = [object Object]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/utils.js":206]
1 anonymous(aGrip = [object Object],  = [object Object]) ["resource:///modules/devtools/VariablesView.jsm":3647]
2 anonymous(aGrip = [object Object], aOptions = [object Object]) ["resource:///modules/devtools/VariablesView.jsm":3388]
3 anonymous(aGrip = [object Object]) ["resource:///modules/devtools/VariablesView.jsm":3314]
4 anonymous(aValue = [object Object], 0, [object Object]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/webconsole/webconsole.js":1220]
    this = [object Object]
5 WCF_logConsoleAPIMessage(aMessage = [object Object]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/webconsole/webconsole.js":1219]

The relevant bit in frame 1 seems to be:

    switch (preview.nodeType) {
      case Ci.nsIDOMNode.DOCUMENT_NODE: {
        let location = WebConsoleUtils.abbreviateSourceURL(preview.location,
                                                           { onlyCropQuery: !concise });

and in frame 0:

    let hookIndex = aSourceURL.indexOf("?");

Per spec, document.location acts like this (see <>):

  The location attribute of the Document interface must return the Location object for that Document
  object, if it is in a browsing context, and null otherwise.

So "preview.location" is null.  Then you get an exception in frame 0.

It's not quite clear to me what behavior devtools want here for documents that are not in a browsing context; the right thing to do will clearly depend on the desired behavior.

And while we're here, can we replace Ci.nsIDOMNode.DOCUMENT_NODE with Node.DOCUMENT_NODE, please?
Component: DOM: Core & HTML → Developer Tools: Console
Ever confirmed: true
Product: Core → Firefox


4 years ago
OS: Windows 8.1 → All
Hardware: x86_64 → All
Though it's a bit odd that the error message says aSourceURL is undefined, not null...  I have no idea why both it and the JS dump think it's undefined, when it should obviously be null...

Unless "preview" is not an actual Document object, of course?  I guess it's possible that by now we're dealing with messages, not actual objects and the thing that didn't define a .location on the message is somewhere in the debugger server.
rielz: please retest with a Firefox nightly, tomorrow or in a couple of days (not sure when a patch that just landed gets into nightlies). We fixed bug 1035198 - aSourceURL is undefined should no longer occur. Thanks!

Comment 4

4 years ago
msucan: Fantastic! Can confirm it's fixed in the latest Nightly (Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0).

(I don't know if or how to close this bug)
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.