Closed
Bug 1264654
Opened 9 years ago
Closed 8 years ago
Stop using Ci.nsIDOMParser in the markup-view
Categories
(DevTools :: Inspector, enhancement, P1)
DevTools
Inspector
Tracking
(firefox50 fixed)
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
People
(Reporter: pbro, Assigned: tromey)
References
Details
(Whiteboard: [devtools-html])
Attachments
(1 file)
For devtools.html (especially the de-chroming part of it, see bug 1263287), we need to make sure client-side code (starting with the inspector) does not use special chrome-only things that aren't going to be available when we run in a content page.
The markup-view uses Ci.nsIDOMParser to parse new attributes entered by the user via the UI:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/inspector/markup/markup.js#49-52
This should be replaced by:
- either an async call to the server to do the same (which would have the advantage that if the debuggee page is running in a browser that parses attributes differently than gecko, then at least we'd get correct results),
- or a client-side Js implementation.
Reporter | ||
Updated•9 years ago
|
Severity: normal → enhancement
Updated•9 years ago
|
Whiteboard: [devtools-html]
Comment 1•9 years ago
|
||
Isn't the standard DOMParser available?
https://developer.mozilla.org/en-US/docs/Web/API/DOMParser
Updated•9 years ago
|
Flags: qe-verify-
Priority: -- → P2
Updated•8 years ago
|
Priority: P2 → P1
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → ttromey
Status: NEW → ASSIGNED
Updated•8 years ago
|
Iteration: --- → 50.1
Assignee | ||
Comment 2•8 years ago
|
||
(In reply to Patrick Brosset <:pbro> from comment #0)
> - either an async call to the server to do the same (which would have the
> advantage that if the debuggee page is running in a browser that parses
> attributes differently than gecko, then at least we'd get correct results),
>
> - or a client-side Js implementation.
I have a patch to use DOMParser; but I am going to take a look at pushing
this into the actor.
Assignee | ||
Comment 3•8 years ago
|
||
(In reply to Tom Tromey :tromey from comment #2)
> I have a patch to use DOMParser; but I am going to take a look at pushing
> this into the actor.
I looked into this a bit today. The use of DOMParser is in markup.js.
It is called from, e.g., here:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/inspector/markup/markup.js#3222
This in turn is called from the inplace editor _apply method, from various spots like:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/inplace-editor.js#1120
Here's where I stopped. This looks fairly synchronous and difficult to untangle.
Also, doing this client side hasn't been a big enough problem so far to try to fix it.
So I'm going to leave it as client side.
Assignee | ||
Comment 4•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/59826/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59826/
Attachment #8763672 -
Flags: review?(bgrinstead)
Comment 5•8 years ago
|
||
Comment on attachment 8763672 [details]
Bug 1264654 - use DOMParser in devtools;
https://reviewboard.mozilla.org/r/59826/#review56800
::: devtools/shared/builtin-modules.js:297
(Diff revision 1)
> = Cu.Sandbox(CC("@mozilla.org/systemprincipal;1", "nsIPrincipal")(),
> {wantGlobalProperties: ["URL"]});
> return sandbox.URL;
> });
> +defineLazyGetter(globals, "DOMParser", () => {
> + return CC("@mozilla.org/xmlextras/domparser;1", "nsIDOMParser");
I wonder if there are any behavior differences between the nsIDOMParser and the web-exposed DOMParser that won't be exercised by our current test suite. r+ either way though, since that's not a specific issue with this patch but a general issue we'll need to tackle eventually with all of the de-chrome work
Attachment #8763672 -
Flags: review?(bgrinstead) → review+
Updated•8 years ago
|
Iteration: 50.1 → 50.2
Assignee | ||
Comment 6•8 years ago
|
||
Assignee | ||
Comment 7•8 years ago
|
||
Comment on attachment 8763672 [details]
Bug 1264654 - use DOMParser in devtools;
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/59826/diff/1-2/
Assignee | ||
Comment 8•8 years ago
|
||
There was a use in netmonitor that I missed because it was imported non-locally.
Assignee | ||
Comment 9•8 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #5)
> I wonder if there are any behavior differences between the nsIDOMParser and
> the web-exposed DOMParser that won't be exercised by our current test suite.
As far as I can tell the two interfaces are implemented by the exact same C++
class. Whatever differences there are (they use different entry points) seem
minor.
Assignee | ||
Comment 10•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Keywords: checkin-needed
Comment 11•8 years ago
|
||
needs rebasing
applying 88a91470495c
patching file devtools/.eslintrc
Hunk #1 FAILED at 3
1 out of 1 hunks FAILED -- saving rejects to file devtools/.eslintrc.rej
patch failed to apply
abort: fix up the working directory and run hg transplant --continue
Flags: needinfo?(ttromey)
Keywords: checkin-needed
Assignee | ||
Comment 12•8 years ago
|
||
Comment on attachment 8763672 [details]
Bug 1264654 - use DOMParser in devtools;
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/59826/diff/2-3/
Comment 14•8 years ago
|
||
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/fx-team/rev/4702e2121828
Use DOMParser in devtools. r=bgrins
Keywords: checkin-needed
Comment 15•8 years ago
|
||
Landed this morning: https://hg.mozilla.org/mozilla-central/rev/4702e2121828
status-firefox50:
--- → fixed
Target Milestone: --- → Firefox 50
Updated•8 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 8 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
•