Closed Bug 1078121 Opened 10 years ago Closed 7 years ago

[e10s] DOM inspector does not work with e10s

Categories

(Other Applications :: DOM Inspector, defect)

Product:
Other Applications
Component:
DOM Inspector
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(e10s+)

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: helpwanted) 

DOM inspector does not work with e10s content document.

*DOM inspector build from src
*DOM inspector 2.0.15 of attachment in Bug 957149
Component: Extension Compatibility → DOM Inspector
Product: Firefox → Other Applications
Make sure that when/if it does support e10s that it will still support browsers or setups without any e10s.
Blocks: e10s-addons
tracking-e10s: + → ---
In Multiprocess Firefox the content is running in another process.

From: http://mxr.mozilla.org/comm-central/source/mozilla/devtools/server/actors/inspector.js?rev=cc2af13f040c#187

// When the user selects a node to inspect in e10s, the parent process
// has a CPOW that wraps the node being inspected.  It uses the
// message manager to send this node to the child, which stores the
// node in gInspectingNode. Then a findInspectingNode request is sent
// over the remote debugging protocol, and gInspectingNode is returned
// to the parent as a NodeFront.

Since this functionality is expected to be present in Firefox we could piggyback on the remote debugging protocol.
Keywords: helpwanted
Jeff, do we care?
Flags: needinfo?(jgriffiths)
Fun fact: most usage of DOMi is Seamonkey, at least according to AMO:

https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/statistics/usage/applications/?last=30

There are a couple of workarounds immediately available to DOMi users:

1. open a non-e10s window
2. use the browser toolbox

I'd be curious to know what the delta of missing capabilities is between those two. I get that we are introducing a papercut here for Mozilla engineers though. 

I don't think we should block on this. I do want to hear from people using DOMi on the Firefox team to see whether it is a better use of time to add remote content support for DOMi vs improving the browser toolbox.
Flags: needinfo?(jgriffiths)
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #7)

> I don't think we should block on this. I do want to hear from people using
> DOMi on the Firefox team to see whether it is a better use of time to add
> remote content support for DOMi vs improving the browser toolbox.
Well, I care. I'm willing to work on this if you can tell me how to do it.
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #7)
> Fun fact: most usage of DOMi is Seamonkey, at least according to AMO

Usage from Firefox users almost definitely dwarfs usage from SeaMonkey users.  DOM Inspector comes installed by default with SeaMonkey, so the numbers you see there for DOMi-on-SeaMonkey should basically be the same as the SeaMonkey installed base, whether those users are actually using DOMi or not.  The numbers for DOMi-on-Firefox, on the other hand, represent people who deliberately installed it at one point or another.
Any user statistics identified as "Firefox 24.9" are ALL in fact Pale Moon users due to how we sanitize and identify update requests to AMO.. We do not nor have any plans to do e10s. So please Comment 1 in mind when making changes to DOMi.
Component: DOM Inspector → Developer Tools
Product: Other Applications → Firefox
(In reply to Matt A. Tobin [:BinOC] from comment #11)
> Any user statistics identified as "Firefox 24.9" are ALL in fact Pale Moon
> users due to how we sanitize and identify update requests to AMO.. We do not
> nor have any plans to do e10s. So please Comment 1 in mind when making
> changes to DOMi.

Hm, the developments start to look interesting in this bug. But I'm tempted to say: Don't fear, Matt. If Philip finally gets the help he asked for (comment #5) and finally takes the bug (see also comment #9) I'm confident that single-process apps and users won't be left stranded on the side of the road. These, however, are a pair of big ifs; but if this bug is not fixed at all it's Firefox+e10s users of DOMi which will be stranded, and forced to fall back on whatever the so-called "Inspector" gadget packaged with Firefox can do.
When is this going to be fixed?  AFAIK the stable version of Firefox 46, slated for release on April 19, has e10s enabled.
(In reply to Gary [:streetwolf] from comment #14)
> When is this going to be fixed?  AFAIK the stable version of Firefox 46,
> slated for release on April 19, has e10s enabled.

AFAIK the plan is to enable e10s in Firefox 46 for users without add-ons so Firebug 2 users should not be affected by the release of Firefox 46.
Jeff, I assume the DevTools team has no plans to change the DOM Inspector add-on?

If so, should this bug be moved back to Other Applications :: DOM Inspector?
Flags: needinfo?(jgriffiths)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #16)
> Jeff, I assume the DevTools team has no plans to change the DOM Inspector
> add-on?
> 
> If so, should this bug be moved back to Other Applications :: DOM Inspector?

The DevTools team has an Inspector widget which is built-in to Firefox (unlike the DOM Inspector add-on which is builtin to SeaMonkey and available as an extension for Thunderbird and SeaMonkey), and in recent bugs there is considerable confusion between this newfangled devtools "Inspector" and the time-trusted "DOM Inspector" add-on. Newbie users of Firefox often don't realize that they are two totally different items of software and file bugs for the one on the Product::Component of the other rather indiscriminately.
s/Thunderbird and SeaMonkey/Thunderbird and Firefox/
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #16)
> Jeff, I assume the DevTools team has no plans to change the DOM Inspector
> add-on?
> 
> If so, should this bug be moved back to Other Applications :: DOM Inspector?

Yup
tracking-e10s: + → ---
Component: Developer Tools → DOM Inspector
Flags: needinfo?(jgriffiths)
Product: Firefox → Other Applications
For clarification to c16 .. There is a specific distinction between built in and bundled.

DOM Inspector is bundled with SeaMonkey but is not built in to the application. When SeaMonkey is built it (after client.py is ran) it is packaged and bundled but still as a normal extension.

I don't know/care what Firefox is doing with their widget which is indeed built into Firefox's devtools but I think the distinction is important.

(Yeah i know it is semantics but I feel it is important to distinguish)
On a related note, there is work underway in bug 1223341 to add the Firefox DevTools UI into SeaMonkey.
(In reply to Matt A. Tobin [:BinOC] from comment #20)
> For clarification to c16 .. There is a specific distinction between built in
> and bundled.
> 
> DOM Inspector is bundled with SeaMonkey but is not built in to the
> application. When SeaMonkey is built it (after client.py is ran) it is
> packaged and bundled but still as a normal extension.

Well, yes, if you wish. DOM Inspector and ChatZilla have their sources in two distinct Mercurial repositories, clones of which are grafted as subfolders of extensions/ onto the mozilla-central clone grafted at mozilla/ onto the comm-central clone when client.py updates it.
As part of building SeaMonkey, DOM Inspector, ChatZilla, the Debug and QA UI which lives in comm-central, and depending on configure settings sometimes even the Lightning calendar which also lives in somm-central, as well as the default and Modern themes, are packaged as XPI add-ons, either at seamonkey/distribution/extensions/ or at seamonkey/extensions/ in the final archive, which depending on platform can be either a .dmg, a .tar.bz2 or an .installer.exe accompanied by a .zip
These XPIs are add-ons recognised as such by the add-ons manager, they can be disabled and enabled at will, but they cannot be removed (i.e. uninstalled). I call them builtin because they are part of the SeaMonkey finished product as distributed: from my point of view DOM Inspector and ChatZilla are an integral part of a "complete" SeaMonkey even if Safe Mode disables them both. In your terminology they are "bundled"; my good though admittedly not native command of the English language does not extend to such fine distinctions.

> 
> I don't know/care what Firefox is doing with their widget which is indeed
> built into Firefox's devtools but I think the distinction is important.
> 
> (Yeah i know it is semantics but I feel it is important to distinguish)

I never called the devtools inspector an add-on; until I see it at work I only have a documentary interest in it; however as QA volunteer I daresay I'm a little annoyed (to say the least) at all those recent bugs about the devtools inspector getting filed in "Other Applications :: Dom Inspector"; then it's only at about the sixth or seventh comment that the reporter says something like "I don't know the DOM Inspector version, it is the one which was installed together with Firefox 43" which shows he meant the devtools widget after all…
glob, can you add the tracking e10s flag to this component?
Flags: needinfo?(glob)
tracking-e10s added to 'Other Applications :: DOM Inspector'
Flags: needinfo?(glob)
Has anyone considered the fact that after Mozilla drops toolkit extensions and XUL shortly after that this extension working with e10s is gonna be moot?
With Firefox 57 only WebExtensions are permitted and are, by default, e10s compatible.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.