<div dir="ltr"><div><div><div><div><div>I still use DOM Inspector occasionally, and I always have to open a new tab before I can open DOM Inspector since it needs to be a non-remote tab.<br><br></div>I would be happy to replace my usage of DOMi with the Browser Toolbox, but these are the things that need to happen first:<br><br></div>1. The Browser Toolbox is *much* slower to start than DOMi. DOMi starts nearly intantaneous and doesn't feel like it is slowing down my system. I understand this has to do with starting up the Debugger, but as I understand it we only start up the Debugger if that was the last used tab. I just tried launching the Browser Toolbox and while a blank window appeared very quickly, I was able to count to 7 before the contents were painted and the view was usable. The view that loaded was the Style Editor. This is on file as bug 1092821.<br><br></div><div>2. The list of sources in the Debugger is not sorted alphabetically after more sources are loaded. This is very obvious when using the Browser Toolbox, as we lazy load much of our code. This makes browsing through the sources to see what is loaded very slow. The built-in search (Ctrl+P) is now faster than it used to be though. The bug about the sources out of order is filed as bug 883702 and it affects the content devtools too.<br></div><div><br>3. Showing all of the attributes in the Inspector is very
 cluttered. This is filed as bug 1090371 and the bug contains a good 
discussion about potential solutions.<br><br></div>4. It is very hard to navigate around the Browser Toolbox using only a keyboard. I am not able to switch to a different frame without using my mouse. This may seem trivial but there are times where I don't want :hover state to change while I am inspecting something. I am able to do this pretty easily and efficiently using DOMi. This is on file as bug 1230356.<br><br></div>5. When a different frame is selected in the Style Editor, the list of files on the sidebar is not reduced to only the ones that apply to that view. If I select a XUL notification/alert dialog ("alert:alert" window), I can find alert-common.css at the bottom of the file list but many of the other stylesheets are not applied to this window but they are still in the list. This is on file as bug 1230358.<br><br></div><div>Thanks for inquiring,<br></div><div>Jared<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 4:43 PM, Jeff Griffiths <span dir="ltr"><<a href="mailto:jgriffiths@mozilla.com" target="_blank">jgriffiths@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The e10s team looked at bug 1078121[1] this morning and asked how<br>
concerned I am about it. I responded in comment 7 ( link below ) and I<br>
*think* my workarounds are reasonable, however I want to ensure that<br>
people are aware of DOM Inspector's limitations wrt e10s and also get<br>
feedback from the Firefox development community on how important DOM<br>
Inspector is to them.<br>
<br>
If you're using DOM Inspector as an indispensable part of your<br>
workflow developing for Firefox Desktop I'd like to hear about your<br>
use case and in particular what is lacking in the Browser Toolbox. No<br>
need to be polite, but please provide links to bugs if you have them.<br>
<br>
Jeff<br>
<br>
[1] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1078121#c7" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1078121#c7</a><br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div><br></div>