Lisa Hewus Fresh [:lfresh] Reporter
	Description • 10 years ago

With a new tab opened and Developer Tools toggled on, the Developer Tools console closes and the Developer Tools toggle becomes deselected in the tools/menu when navigating to another page.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 1 • 10 years ago

I can't reproduce this. Which specific page does that happen at and do you see any errors in the Browser Console (Cmd-Shift-J)?

	Lisa Hewus Fresh [:lfresh] Reporter
	Comment 2 • 10 years ago

Here are the steps that reproduce the issue:

1. Open nightly with new profile
2. Enable e10s and restart
3. Open a new tab
4. Toggle Developer Tools on
5. Navigate to a different web page

If e10s is not enabled Developer Tools console does not close.

	Scott Odle
	Comment 3 • 10 years ago

Can reproduce. To clarify a bit, this happens when the devtools are opened on the New Tab page, then another page is navigated to.

	Scott Odle
	Comment 4 • 10 years ago

[Tracking Requested - why for this release]:

	Paul Silaghi, QA [:pauly]
	Comment 5 • 10 years ago

(In reply to Scott Odle from comment #3)
> Can reproduce. To clarify a bit, this happens when the devtools are opened
> on the New Tab page, then another page is navigated to.
Confirmed 35.0a1 (2014-09-18) Win 7 x64

	Benjamin Kerensa [:bkerensa]
	Comment 6 • 10 years ago

Tracking this! Thanks Ascend!

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 7 • 10 years ago

Jeff - is this on the Dev tools radar?  Since we're not shipping e10s yet I'm untracking, but wanted to flag you to ensure it got prioritized.

	Jeff Griffiths (:canuckistani) (:⚡︎)
	Comment 8 • 10 years ago

Lukas: I agree - this should block enabling e10s by default in Aurora though.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 9 • 10 years ago

Marking for 37 in that case, if that's where we might first try it on by default, otherwise bump this out to 38.

	Brian Grinstead [:bgrins]
	Comment 12 • 9 years ago

The following error appears in the console when this happens:

Error: Connection closed
Stack trace:
Front<.destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1113:23
exports.WalkerFront<.destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:2708:5
frontProto/</proto[name]/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1331:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:40
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:11
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:11
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
Front<.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1208:7
DebuggerClient.prototype.onPacket@resource://gre/modules/devtools/dbg-client.jsm:897:7
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:545:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
 protocol.js:18
Error: Connection closed
Stack trace:
Front<.destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1113:23
exports.WalkerFront<.destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/inspector.js:2708:5
frontProto/</proto[name]/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1331:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:40
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:11
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:40:11
then@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:20:43
resolve@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/deprecated-sync-thenables.js:72:11
Front<.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:1208:7
DebuggerClient.prototype.onPacket@resource://gre/modules/devtools/dbg-client.jsm:897:7
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:545:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14

	Brian Grinstead [:bgrins]
	Comment 13 • 9 years ago

This seems to happen when going from any non-e10s page (new tab, about:config) to an e10s page.

For instance, if you:
1) go to a new tab, open toolbox then navigate to about:config the toolbox works fine.
1) go to a new tab, open toolbox then navigate to mozilla.com the toolbox closes.
1) navigate to mozilla.com, open toolbox then navigate to about:config the toolbox remains opened but in an extremely broken state that you can't even close

	Brian Grinstead [:bgrins]
	Comment 14 • 9 years ago

So it appears that certain about: pages are served as non-e10s even when it's enabled (based on there not being an underline in the tab title - this may not be a correct assumption).  Should spend time fixing the transition between these pages and normal web content, or will all about pages be e10s-enabled before enabling on Aurora?

	Chris Peterson [:cpeterson]
	Comment 15 • 9 years ago

Dave: do we plan to move all about: page loading to the content process?

	Dave Townsend [:mossop]
	Comment 16 • 9 years ago

(In reply to Chris Peterson [:cpeterson] from comment #15)
> Dave: do we plan to move all about: page loading to the content process?

I think it's unlikely that all about: pages will be loaded in the content process. Many pages like about:addons, about:preferences, about:permissions would be an extreme amount of work to convert, far more than my understanding of the remaining things that are broken with respect to switching processes. I'm hopeful that about:newtab will be switched before release since that is one of the most common cases that users will hit.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 17 • 9 years ago

I'm dropping tracking as e10s is not shipping in 37. As this bug is already tracking e10s, I don't see the need for relman to track until e10s gets past Nightly.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 19 • 9 years ago

The behavior here is now different, likely after bug 1128027.

Now, with the console open, when navigating from about:newtab to content in e10s, I get only the error:

TypeError: docShell is undefined (webbrowser.js:52:6)

Also, the console does not function.  You can close the broken toolbox, but attempting to open a fresh one gives more errors, like:

TypeError: this.hud.jsterm is null panel.js:37:8
A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Date: Tue Mar 10 2015 12:49:46 GMT-0500 (CDT)
Full Message: TypeError: this.doc is undefined
Full Stack: Toolbox.prototype.selectTool@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox.js:1050:9
DevTools.prototype.showToolbox/hostPromise<@resource:///modules/devtools/gDevTools.jsm:404:18
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:867:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688:37

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 20 • 9 years ago

Changes could also be due to bug 1059308.

	Alexandre Poirot [:ochameau] Assignee
	Comment 22 • 9 years ago

The particular scenario that is failing here is when we morph a non-e10s tab
into a e10s one. the xul:browser element get its docshell destroyed,
we already handle this special case here:
  http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js#1059
And we expect to close the toolbox in such scenario,
when we kill the original top level docshell
and no other top level one exists.

But we had an exception because of this.docShell being undefined,
that shouldn't happen, it should always be defined (ok, may be only during cleanup...).
It was undefined because browser.docShell ends up being undefined here.
I already faced similar issue in ChromeActor and defined docShell as a value
and not a dynamic getter, so I'm applying the same fix everywhere.
(Here we only care about BrowserTabActor, but that doesn't cost much to apply the same behavior to ContentActor)

	Alexandre Poirot [:ochameau] Assignee
	Comment 23 • 9 years ago

FYI, the precise exception was:
TypeError: docShell is undefined
getChildDocShells@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:52:7
TabActor.prototype.docShells@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:709:12
TabActor.prototype._notifyDocShellDestroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1107:11
TabActor.prototype._onDocShellDestroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1028:5
TabActor.prototype.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1003:7
updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1493:13
updateBrowserRemotenessByURL@chrome://browser/content/tabbrowser.xml:1540:1

	Alexandre Poirot [:ochameau] Assignee
	Comment 24 • 9 years ago

Note that this patch is going to fix the exception and close the toolbox when we are morphing non-e10s tab into e10s one. It is very challenging to keep the toolbox opened in such scenario. We could followup with something to reopen the toolbox...

	Alexandre Poirot [:ochameau] Assignee
	Comment 25 • 9 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bad8949cd1fe

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 26 • 9 years ago

Comment on attachment 8578739 [details] [diff] [review]
patch v1

Review of attachment 8578739 [details] [diff] [review]:
-----------------------------------------------------------------

Cool, this at least goes far enough to fix the exceptions and lets the toolbox close properly.

But I suppose to really fix this bug, we would need to somehow reopen the toolbox.  You right, it's definitely tricky as we're connecting to a completely different server after the transition.

Any thoughts on a good design for this?  I guess the toolbox could watch whether the user chose to close the toolbox vs. it was aborted because of the connection died because of this navigation, and the reboot in the navigation case.  Or maybe the server can send a "I'm navigating to a new server, you should reboot the toolbox" event?  Not sure what's best.

	Alexandre Poirot [:ochameau] Assignee
	Comment 27 • 9 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #26)
> Any thoughts on a good design for this?  I guess the toolbox could watch
> whether the user chose to close the toolbox vs. it was aborted because of
> the connection died because of this navigation, and the reboot in the
> navigation case. 

In the code where I shutdown the TabActor (calling exit)
  http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js#1058
It is quite challenging to identify the difference.
Especially when you think about the browser toolbox usecase, where a root docshell (the original browser.xul window for ex) closes. That's totally fine to switch to any still existing top level window (another browser.xul, the browser console, ...). Otherwise, we end up calling exit in many scenarios: app/tab/firefox closing. This is where it is hard to differenciate closing versus e10s morphing.

> Or maybe the server can send a "I'm navigating to a new
> server, you should reboot the toolbox" event?

That's not easy to detect, but may be that's the best option.
BrowserTabActor may save the remote attribute and on TabActor's exit,
we may check if the remote status changed... (if it changed soon enough?)
Or may be the xul:(remote)browser XBLs are dispatching events?

At the end I don't really know what's best but yes we would ideally find some ways to identify when we should restart automagically a toolbox.

	Carsten Book [:Tomcat]
	Comment 28 • 9 years ago

https://hg.mozilla.org/integration/fx-team/rev/295944fe65f9

	Carsten Book [:Tomcat]
	Comment 29 • 9 years ago

sorry had to back this out for test failures like https://treeherder.mozilla.org/logviewer.html#?job_id=2308559&repo=fx-team

	Alexandre Poirot [:ochameau] Assignee
	Comment 30 • 9 years ago

Previous patch introduced a docShell leak.
I have to nullify docShell on actor detach.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e9ff4141f036

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 31 • 9 years ago

https://hg.mozilla.org/integration/fx-team/rev/33b342d47748

	Eddy Bruel [:ejpbruel]
	Comment 32 • 9 years ago

With ochameau's fix, the toolbox still closes when a tab is opened from the New Tab page, but can now be reopened again, making this problem much less severe.

Consequently, I'd like to propose to downgrade this bug to M7.

	Mike Conley (:mconley) (:⚙️)
	Comment 33 • 9 years ago

I'm guessing this problem is caused by us switching from a non-remote browser to a remote browser when browsing away from about:newtab (about:newtab can only load in non-remote browsers right now).

The simplest solution here might be to just make about:newtab work in remote browsers. I think that's bug 1021654.

	Ryan VanderMeulen [:RyanVM]
	Comment 34 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/33b342d47748

	Alexandre Poirot [:ochameau] Assignee
	Comment 35 • 9 years ago

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #33)
> I'm guessing this problem is caused by us switching from a non-remote
> browser to a remote browser when browsing away from about:newtab
> (about:newtab can only load in non-remote browsers right now).

Yes.

> The simplest solution here might be to just make about:newtab work in remote
> browsers. I think that's bug 1021654.

Yes, definitely!

	Dave Townsend [:mossop]
	Comment 36 • 9 years ago

(In reply to Alexandre Poirot [:ochameau] from comment #35)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #33)
> > The simplest solution here might be to just make about:newtab work in remote
> > browsers. I think that's bug 1021654.
> 
> Yes, definitely!

Well, that all depends on how complex fixing this is, because fixing about:newtab is quite complex apparently. Also you'll still have this problem when navigating from other non-remote tabs like about:preferences and about:addons.

	Alexandre Poirot [:ochameau] Assignee
	Comment 37 • 9 years ago

I'm not sure this issue is relevant for other special tabs like about:preferences/about:addons.
I can easily imagine someone to open tools on about:newtab/about:home and then load its webpage,
whereas I can't imagine someone willing to do the same thing with the other about: pages.

But really, this issue doesn't look like a big deal now that the toolbox doesn't crashes anymore.
So it shouldn't increase bug 1021654 priority...

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 41 • 9 years ago

Now that bug 1021654 has been fixed, is it a good time to address this? This is a fairly prominent e10s papercut.

	Mike Conley (:mconley) (:⚙️)
	Comment 42 • 9 years ago

While the Content Services has succeeded in making about:newtab render in the content process properly, I think a lot of that work is being morphed as they work on their project to host the about:newtab remotely.

Hey oyiptong, do you know if the current about:newtab page can be rendered properly in the content process? I know that ursula got really far along but got bogged down by some test failures. Did that work get side-tracked with the about:remote-newtab work?

	Olivier Yiptong [:oyiptong]
	Comment 43 • 9 years ago

I think the newtab page can be rendered in a content process.

However, the existing newtab content code is not quite ready. While Ursula made a lot of progress in the implementation, the mochitests requires a lot of work to port over.

Yes, the patches ursula made have partly been absorbed/modified and partly discarded (mostly the in-content stuff).

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 46 • 8 years ago

A couple of duplicate bugs were reported recently. Is anyone still working on this issue? It may be good to fix if people are noticing it enough to report issues.

	Brian Grinstead [:bgrins]
	Comment 47 • 8 years ago

Should this be morphed into 'make the newtab page run in the content process' as per Comments 42 and 43?  Bug 1021654 was resolved but it still seems to be an issue so maybe there's still work to do.

	Alexandre Poirot [:ochameau] Assignee
	Comment 48 • 8 years ago

A reasonable option from devtools side would be to at least reopen the toolbox.
We could listen for Tab remoteness change event and reopen one.

Keeping the toolbox in-place sounds like a very complex work that I have no idea how to do.

Reseting assignement as I'm leaving for PTO in the next days.

	u564464
	Comment 50 • 8 years ago

TorBrowser 6.0.5 (based on based on Mozilla Firefox 45.4.0) on Mac OS X is able to keep the Inspector open when browsing to a site from a blank new tab page.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 51 • 8 years ago

(In reply to spammonster2011 from comment #50)
> TorBrowser 6.0.5 (based on based on Mozilla Firefox 45.4.0) on Mac OS X is
> able to keep the Inspector open when browsing to a site from a blank new tab
> page.

I would assume e10s is disabled in that browser since it was also disabled in regular Firefox 45.  This issue only occurs when e10s is enabled.

	Honza Bambas (:mayhemer)
	Comment 52 • 8 years ago

Any plans on fixing this then?  

It sometimes makes diagnosing even platform problems impossible or way harder.  Dev tools are useful, but not when just disappearing after pressing the enter key in the url bar...

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 53 • 8 years ago

(In reply to Honza Bambas (:mayhemer) from comment #52)
> Any plans on fixing this then?  

At the moment, we've assumed it was a relatively low priority issue, so there isn't an active plan.  It's somewhat tricky, as we'd need to signal the DevTools UI to "restart" essentially and reconnect to a different process.

> It sometimes makes diagnosing even platform problems impossible or way
> harder.  Dev tools are useful, but not when just disappearing after pressing
> the enter key in the url bar...

Do you have to start from the new tab page to investigate these platform problems?  Possible workarounds are:

A. Open the toolbox on some random web content (not about:newtab) and enter your new location there
B. Go to the target page, open toolbox, then refresh page

	Honza Bambas (:mayhemer)
	Comment 54 • 8 years ago

Aha!  now I understand.  If there is no content process (no page so far ever open during the browser's session) devtools will connect to "something" (?).  But when I navigate to a page, a new - actually the very first - content process is lazily started, that "something" goes away?  so that devtools close itself and don't know about the new process to connect to?

Could we start the/a content process when devtools are open the first time and connect them to that process, while that process would also be the one to use for load of the page being navigated to?  Simply said: warm a content process up when devtools open.  Would that solve the problem?

Or is it more complicated?  Probably is if we run multiple content processes and there is some kind of coalescing like per origin/tld or something which is not known at the time before user starts actual navigation...

Still, this all sounds to me a bit like a bad architecture...



Sometimes I simply want to diagnose the very first load during the browser session.  Anyway, the workaround may be used in most cases.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 55 • 8 years ago

(In reply to Honza Bambas (:mayhemer) from comment #54)
> Aha!  now I understand.  If there is no content process (no page so far ever
> open during the browser's session) devtools will connect to "something" (?).
> But when I navigate to a page, a new - actually the very first - content
> process is lazily started, that "something" goes away?  so that devtools
> close itself and don't know about the new process to connect to?
> 
> Could we start the/a content process when devtools are open the first time
> and connect them to that process, while that process would also be the one
> to use for load of the page being navigated to?  Simply said: warm a content
> process up when devtools open.  Would that solve the problem?

DevTools has a front end UI (the toolbox) that always runs in the main process with other browser UI.  There is also a back end DevTools server that needs to be running in whichever process holds the content we are interested in (main process or content process).

In the case of the new tab page, about:newtab is currently not allowed to load in content process, it requires the main process.  However with e10s on, regular web content _is_ loaded in the content process.  So, when you enter a URL in the location bar from the new tab page, the browser UI checks the location and flips the tab's remoteness from main to content, causing both the content and the corresponding DevTools data about the content to go away suddenly.

Warming up a content process wouldn't help here, since it's really the _transition_ from one process to the other that is the issue.  It's possible we could adapt DevTools to watch for such a thing and "restart" the front end or something.

There was a project in place to convert about:newtab to remote content, but that effort has stalled.  If it was completed, there would not be a process transition anymore, so the problem would go away (for this specific case at least).

	Alexandre Poirot [:ochameau] Assignee
	Comment 57 • 8 years ago

That patch restore the toolbox automatically when switching the remoteness of a tab.
The toolbox is still going to be destroyed, but a new one is going to be spawn.
We may be able to tweak this patch, but I don't see how to not close the toolbox at all without involving a significant work within devtools frontent to be able to swap the target/actors of a toolbox.
If that patch/behavior is not good enough, it may be better time spent finishing the about:newtab patch than doing something complex on devtools...

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 58 • 8 years ago
mozreview-review

Comment on attachment 8803881 [details]
Bug 1068400 - Restore toolbox when switching from in-parent-process to OOP tab.

https://reviewboard.mozilla.org/r/88090/#review87770

Cool, this works well in my testing!  The toolbox does restart, but that's a lot better than it just disappearing!

So, breakpoints, etc. are lost with this approach, but hopefully that's less strange than it totally going away for no obvious reason.

Hopefully we'll get more feedback about this once it lands.

::: devtools/client/framework/target.js:562
(Diff revision 1)
> +        break;
>      }
>    },
>  
> +  // Automatically respawn the toolbox when the tab changes from being
> +  // loaded within the parent process to loaded from a content process.

It works both ways, content -> parent and parent -> content, so this comment should be more general.

	Alexandre Poirot [:ochameau] Assignee
	Comment 60 • 8 years ago

Tests are very unhappy. The test really doesn't like running on build machines and  devtools/client/responsive.html/test/browser/browser_toolbox_swap_browsers.js broke on e10s.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 64 • 8 years ago
mozreview-review

Comment on attachment 8805095 [details]
Bug 1068400 - Test against about:robots instead of about:newtab which mess up with addTab helper (never resolves)

https://reviewboard.mozilla.org/r/88946/#review89418

This seems fine, please squash when landing.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 65 • 8 years ago
mozreview-review

Comment on attachment 8805094 [details]
Bug 1068400 - prevent reopening toolbox during rdm tab dance

https://reviewboard.mozilla.org/r/88944/#review89438

Thanks for testing this case!  Ideally it would be possible to avoid RDM specifics like this, but I don't see a good way around it in this case, so this seems like the pragmatic choice.

::: devtools/client/responsive.html/browser/swap.js:55
(Diff revision 1)
>    };
>  
>    return {
>  
>      start: Task.async(function* () {
> +      tab.setAttribute("data-responsive-mode", "true");

An attribute seems like overkill here, since we're not applying CSS based on this, for example.

Instead, let's go with something like:

```
tab.isReponsiveDesignMode = true;
```

along with

```
delete tab.isReponsiveDesignMode;
```

when closing RDM.

	Pulsebot
	Comment 68 • 8 years ago

Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d8524ebd999
Restore toolbox when switching from in-parent-process to OOP tab. r=jryans

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 69 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/2d8524ebd999

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 70 • 8 years ago

With the current approach, the DevTools UI restarts when going from about:newtab to content, so breakpoints, console output, etc. are all discarded.  If that's considered to be a problem, please file a new bug for this issue.

	stalingraddd
	Comment 71 • 8 years ago

I still have this problem on latest Firefox 51.0a2 (2016-11-14) on Windows 10 x64, if i don't use e10s mode, developer tools doesn't auto-close when opened in new tab then navigating to a site, but in e10s it auto-closes, so every time i want to do something i have to open a site than open DevTools.
Proof https://drive.google.com/open?id=0B2whZWKL2gRSYVd0SDZjR1hJdkE

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 72 • 8 years ago

(In reply to stalingraddd from comment #71)
> I still have this problem on latest Firefox 51.0a2 (2016-11-14) on Windows
> 10 x64, if i don't use e10s mode, developer tools doesn't auto-close when
> opened in new tab then navigating to a site, but in e10s it auto-closes, so
> every time i want to do something i have to open a site than open DevTools.
> Proof https://drive.google.com/open?id=0B2whZWKL2gRSYVd0SDZjR1hJdkE

The last change here landed as part of Firefox 52, so you'll either need to try Developer Edition 52 or else wait until 52 makes it to the channel you are using.