1569859 - Auto-open devtools for newly opened tabs/windows

Status: RESOLVED FIXED

(DevTools :: General, enhancement, P3)

Description

[Karl Dubost💡 :karlcow]

Not sure if this should be here.
Probably related to Bug 905327

There is a class of issues which are hard to diagnose because they happen in the transition in between two tabs. Sites opening a new tab/window for login, for downloading files, for enabling a configuration.

It would be cool to have a mode where we can ask the devtools to track this kind of stuff:

1. Be on a tab for a website
2. Make an action on this site which will open a new tab
3. Have devtools track the opening of the new tab.
4. Have devtools opened on the old tab and the new tab (separate windows is fine for each tab is fine).
5. Have the devtools started BEFORE any interactions with regards to the site happened in the new tab (network included).
6. Have the possibility to tell the devtools to block the auto-destruction of the tab (some login sites for example) so we do not lose the context of the devtools.

Comment 2

[Thayne]

Chrome has a feature like this. There is a setting for the Chrome DevTools called "Auto-open DevTools for popups". If it is enabled, then if you have the devtools open for a tab, and that tab opens a new window or tab, then chrome will open a new instance of devtools for the new window/tab.

Comment 3

[:Harald Kirschner :digitarald]

Alex, is this something we can do easier with the new actor/process architecture to connect to processes early or should inform the design?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 6

[:Harald Kirschner :digitarald]

(clear ni? for Alex)

Julian, is this something we can do easier with the new actor/process architecture to connect to processes early or should inform the design?

Comment 7

[:Harald Kirschner :digitarald]

(forgot ni?)

Julian, is this something we can do easier with the new actor/process architecture to connect to processes early or should inform the design?

Comment 8

[Julian Descottes [:jdescottes]]

I don't think it would be easy to implement, especially the part about having devtools opened before anything happened on the page. We would need to have something similar to what we do with --wait-for-debugger on startup.

However, using the Multiprocess Browser Toolbox (devtools.browsertoolbox.fission set to true in about:config) should achieve a similar goal, as far monitoring requests and JS execution goes.

Comment 9

[Gabi]

not sure if there is a way to vote for this bug, but it would be really useful to have such feature.

Comment 10

[Alexandre Poirot [:ochameau]]

+1 about the Multiprocess Browser Toolbox (MBT), it should already be a way to somehow debug any new tab/popup.
But I could easily understand that today, the MBT can be too slow to use in some case, and overwhelming with data coming in from all the tabs.

So I think it would still be worth having this implemented.
I see two ways for implementing this.

New Toolbox

This is what has been described so far in this bug.

Tests added in bug 1586830 highlighted a few interesting implementation detail of window.open.
When using window.open there is actually more than one WindowGlobal being instantiated. And you may distinguish the various one via document.isInitialDocument.
This other phabricator, which will probably not land highlighted even better each intermediate WindowGlobal.

A first step would be to identify which WindowGlobal related to a new popup. These tests will help understand how the platform works.
Then, we should probably have some code in DevToolsFrameChild.handleEvent for DOMWindowCreated, which:

• if the new WindowGlobal's browserId is different from the current watcher, we won't instantiated a new target, but,
• if the new WindowGlobal is a new popup related to our browserId, then
  => Do somehow pause the page load.

Work from bug 1717005 probably helped understand platform API about how to pause a given thread.
Then, in parallel to that we should open a new toolbox, spawning its own new Watcher and DevToolsFrame JS Window Actor,
and will resume the thread once "the toolbox is initialized enough". i.e. when all resources are being watched. i.e. most likely once Toolbox.open resolves.

Doing this sounds like a 2 weeks and more task.
As it requires knowledge on:

• how to pause a thread
• how to spawn a new toolbox and how it initializes itself
• watcher actor and DevToolsFrame
• how to synchronize server and client with two servers and two clients (one pair per toolbox!)
  But again, even if fission did not make this easier to implement, it made it clearer by forcing use to better understand key points.

Debug popups from main page toolbox

The original tab's toolbox, from which we opened the popup, would be able to debug the popup.
We would leverage nicely all the work we did for fission. To do that, we would only have to relax the checks where we only accept WindowGlobal matching the watcher's browserId.
For example:
https://searchfox.org/mozilla-central/source/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm#64-68
https://searchfox.org/mozilla-central/rev/c0fc8c4852e927b0ae75d893d35772b8c60ee06b/devtools/server/actors/watcher/target-helpers/utils.js#60-62
Doing this wouldn't require to pause the new popup while the toolbox is loading.
This may help reproduce some bug which are race conditions as we wouldn't change significantly the timings of the popup load.

Doing this sounds like a one week or two task.

But unless the Toolbox is displayed as a Window, this behavior can probably be confusing...
This is probably easier to implement, but may be not the best UX. Especially given that we now force loading all popups to new tabs.
If popups, were still opening real popups, this would actually be a nice UX. As real popup, without browser chrome, can't have any toolbox.

Comment 11

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1569859 - [devtools] Automagically move the toolbox between the original tab we debug and its popups.

Start spawning DevTools WindowGlobal target actors for popups
that originates from the tab we are currently debugging.

This is introducing some complexity in the way we filter out the WindowGlobal
we should consider or not. Before this patch it was quite straightforward.
We accepted all WindowGlobal's matching the tab's browserId.
Now we also accept the WindowGlobal whose opener's browserId matches.

Comment 12

[Alexandre Poirot [:ochameau]]

In the current patch queue:
https://phabricator.services.mozilla.com/D131802
I'm implementing the second option of comment 10: debug the popup from the original tab's toolbox, so that both the original tab and the popup are debugged via the same toolbox.
In order to make that more usable, I ended up introducing some non-trivial code to move around the toolbox between the two tabs (original tab and popup's tab).
I'm using the new target selection feature (the iframe dropdown) to automatically select the popup document or the original tab document when moving between the two tabs in Firefox UI. It allows to automatically display the right document in the inspector, or change the evaluation context of the console. This particular feature makes it hard to know that's actually the same toolbox. You may as well think that a new toolbox dedicated to the popup as you evaluate in it and see its document in the inspector.

shared, moving toolbox for tab and popup

Pros:

• the toolbox is the same between the two documents, so that the panels state is 100% identical. If you set a breakpoint we have a strong guarantee that it is applied to the two documents. You will typicaly not have two distinct set of breakpoints between the two docs.
• in some panels, you may care about the execution order between the two documents. For example, you could see the order of console.log calls between the original tab and the popup. This can only be possibly with a shared toolbox.
• in term of implementation, it is trivial to catch early logs and break during page load without much side effects.
• it should work almost seemlesly the same when debugging remote devices
• if the popup is opened in a new independant smaller window, we may more easily debug it from the original tab toolbox. That, rathen that expanding the size of the popup to show the DevTools decently.
• this new pattern may open new opportunities, like a shared toolbox for all tabs, which may set optionaly set breakpoints for all tabs and could be made visible anytime a tab triggers a breakpoint. A somewhat browser toolbox restricted to tabs.

Cons:

• suddently, a toolbox can debug two distinct tabs, which may be something to learn and understand. You will most likely have to learn how the iframe dropdown works in order to easily switch devtools between the two documents without switching between the two tabs in firefox UI.
• in term of implementation, it isn't trivial to move around the toolbox between the two tabs. It also breaks various old time invariant (one tab = one toolbox)

load freeze, auto opening of toolbox and toolbox per tab

I could always drop this in favor of the other option. Which is to freeze the page load until the toolbox is opened.
Pros:

• this may simplify our implementation in DevTools
• it doesn't change the behavior of toolbox per tab, so it may be less confusing to users

Cons:

• it may have side effects on the popup load timings. This may make chasing race condition during a popup load much harder.
• this would require some special code to auto open a toolbox if we want to support remote debugging
• it is impossible/hard to debug code ordering issues between the two documents

shared toolbox for tab and popup, but only visible as an independant window

A third option would be to revisit something I tried before this patch. Force switching the toolbox to be visible in an independent OS Window and do the same as the current patch. It simplifies a bit the implementation as I would no longer have to move the toolbox between the two tabs. Instead we would only need to focus it correctly and still use the target selection to change the focus of the toolbox.

Comment 13

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1569859 - [devtools] Spawn WindowGlobal targets for popup opened by the currently debugged tab

For now, we only do that when "devtools.popups.debug" is manually set to true.

This is introducing some complexity in the way we filter out the WindowGlobal
we should consider or not. Before this patch it was quite straightforward.
We accepted all WindowGlobal's matching the tab's browserId.
Now we also accept the WindowGlobal whose opener's browserId matches.

With this patch only, popups start appearing in the iframe dropdown.
You still have to manually switch to the popup via the dropdown to debug it in the inspector or console.
In the debugger, you will already start seeing the popup source and break on it.

Comment 14

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1569859 - [devtools] Always return sync content when using SourcesManager.urlContents with partial=true.

With popup debugging (next patches), we trigger a race condition in this code
where SourcesManager.urlContents is called after devtools-html-content is fired.
i.e. after the HTML document is parsed.
This lead to return an async promise instead of an immediate value.
This confuses SourceActor._getStartLineColumnDisplacement which no longer apply breakpoints right away.
We miss early breakpoint support for popups.

This isn't easy to reproduce beyond popup debugging,
in next changeset, browser_dbg-breakpoints-popup.js's testPausedByBreakpoint covers this.

Comment 15

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1569859 - [devtools] Fix SourceActor's url having stack trace in it.

Debugger.Source.url attribute may be of the form:
"http://example.com/foo line 10 > inlineScript"
because of the following function js::FormatIntroducedFilename:
https://searchfox.org/mozilla-central/rev/253ae246f642fe9619597f44de3b087f94e45a2d/js/src/vm/JSScript.cpp#1816-1846
This isn't so easy to reproduce, but in next changeset, browser_dbg-breakpoints-popup.js's testPausedInTwoPopups covers this

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5b1158612d0d
[devtools] Spawn WindowGlobal targets for popup opened by the currently debugged tab r=nchevobbe,devtools-backward-compat-reviewers
https://hg.mozilla.org/integration/autoland/rev/01825e43f450
[devtools] Always return sync content when using SourcesManager.urlContents with partial=true. r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/cd1af14d868c
[devtools] Fix SourceActor's url having stack trace in it. r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/8dec33948dff
[devtools] Automagically move the toolbox between the original tab we debug and its popups. r=nchevobbe

Comment 17

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/5b1158612d0d
https://hg.mozilla.org/mozilla-central/rev/01825e43f450
https://hg.mozilla.org/mozilla-central/rev/cd1af14d868c
https://hg.mozilla.org/mozilla-central/rev/8dec33948dff

Comment 18

[gerrit.huebbers]

I'm on 98.0 (64-bit), I have set devtools.popups.debug to true, but clicking on a <a href="..." target="_blank">...</a> link still opens a new tab without dev tools open (and therefore making it impossible to investigate request headers such as Referer on the originating popup-creating HTTP request).

I also cannot find any configuration option for "having Developer Tools open automatically for popups" in the Developer tools settings. Am I missing something?

Comment 19

[Alexandre Poirot [:ochameau]]

(In reply to gerrit.huebbers from comment #18)

I'm on 98.0 (64-bit), I have set devtools.popups.debug to true, but clicking on a <a href="..." target="_blank">...</a> link still opens a new tab without dev tools open (and therefore making it impossible to investigate request headers such as Referer on the originating popup-creating HTTP request).

Thanks for the report.

It looks like target="_blank" isn't considered as a popup.
window.opener of the new opened tab is null.
So that this new tab is considered as a new completely distinct tab.
It doesn't work because of this behavior. The current implementation is based on the opener attribute.

So for now, this feature wouldn't work for this usecase.
You should be able to see the network requests via the Browser Toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

I also cannot find any configuration option for "having Developer Tools open automatically for popups" in the Developer tools settings. Am I missing something?

This feature is still experimental, we will probably turn it on once it is ready for use.

Comment 20

[Thayne]

It looks like target="_blank" isn't considered as a popup.
So for now, this feature wouldn't work for this usecase.

fwiw, target="_blank" is a pretty important usecase for me for this functionality. So I hope it is part of the final solution. Thank you for your work!

Comment 21

[lijingmu]

auto open devtools for a new tab is also pretty important for automation and browser extension. Hope it is in the final solution. Thanks!