1588697 - [META] Make target selection consistent across the toolbox

Status: NEW

(DevTools :: General, task)

Description

[Nicolas Chevobbe [:nchevobbe]]

There are a few way people can change the target of some of the panel/the toolbox in DevTools:

• The iframe selector in the toolbox (focus on the selected document in the inspector, changes the execution target of the console)
• The thread selector in the debugger
• Being paused in the debugger (changes the execution target of the console)
• The cd command in the console (only impacts the console execution target)
• Having a selected element in the inspector and evaluating $0 in the console

It would be nice to have a consistent way of dealing with such interaction to make it clear for the user that the context is different from the default one.

---

We could use this doc as a starting point for some discussion around this topic that might become more important with Fission around the corner.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

We already have a document with some information/thoughts about this https://docs.google.com/document/d/1pI4Ool0oxhhZ01dHmRv50DgjO49a5_1NFccbtC-9rKc/edit#heading=h.bn38te3qtxzp

Comment 3

[Alexandre Poirot [:ochameau]]

In addition to Sole's document, I wrote some more technical description of a few of these target selections in bug 1567841 comment 1.

Comment 4

[Victoria Wang [:victoria]]

Is it time for me to re-integrate this doc into my brain? (I read it before but already forgot everything 😅)

What is the timeline for this?

Comment 6

[Alexandre Poirot [:ochameau]]

PRD document:
https://docs.google.com/document/d/12N08gQsOeHGUz_aZRX3DcuW84zD29M7B2DSZsymhY8Q/edit?ts=5da82c48

(In reply to Victoria Wang [:victoria] from comment #4)

Is it time for me to re-integrate this doc into my brain? (I read it before but already forgot everything 😅)

What is the timeline for this?

We are most likely going to:

• hold off doing anything regarding toolbox-wide target changes. Especially change anything around the iframe drop down menu. Hold off, until we have a nice story to tell around all the contextual changes all over the toolbox. So hold off on:
  • bug 1588696: synchronise cd(iframe) console command with the toolbox iframe dropdown.
  • bug 1169553: allow console to target "related ressources", like (Service) Workers of the page, iframes, ...
  • bug 1413872: allow console to target WebExtension's content script which executes against the current page.
• proceed with some magical implicit contextual changes of the console input, and only the console, because of fission. Like:
  • bug 1580165: change the context of the console if $0 is present in the console input -or-
  • bug 1588682: change the context of the console based on markup-view selected node.
  • bug 1567849: change the console input if we used reps context menu, like "Copy object".
• bug 1579102: select different context for the console from the debugger. This one is on the edge of these two categories. This looks more like a new feature rather than a necessary fix. And it introduces a new cross panel interaction regarding the scope of the console input. I'm hesitant to hold off on this one until we better know where we are going overall. But it would be very handy to have something...

By proceeding as-is with the few bugs I mentioned, it means that the context into which the console input is going to be evaluated can suddently change based on your current interaction.
Before fission, the console input was always evaluated in the global of the top-level document loaded in the tab -or and only that exception- in the context of the currently hit breakpoint if we are paused. The context of the breakpoint may be the global ojbect of an iframe, or a worker global. But I think this is pretty clear. The debugger toolbox button becomes green and so we clearly significates that we are paused.
After fission, the console input may suddently executes againt some other globals, without being paused. We may execute into: the global of the iframe we selected in the markup view, the global of an iframe from which we copied an object from Object Inspector's "Copy object" context menu, ...

In the immediate future, we are most likely going to do these implicit changes without any UI visualization. For now, all this is going to happen only within the Omniscient Browser Toolbox and behind the related preference. It sounds fine, right?
But as we start supporting real fission, we may have to:

• introduce a clear visualization that the console evaluation context changed and why,
• introduce a way to change the context of the console on-demand (bug 1579102, or better, some toolbox-wide UI).

We may want this to be figured out before shipping real fission debugging.
("real fission" debugging is about debugging regular tabs, with a regular web toolbox, with Firefox fission mode turned on)
Note that I did not mentioned toolbox wide changes here. i.e. the changes that do not only impact the console input, but everything, like the iframe dropdown menu. It isn't a blocker for Fission. It rather sounds like a nice-to-have improvement, which happen to also be about context changes. But we may have to kill two birds with one stone here?

So. In term of timeline.
We are going to proceed with the list of bugs I mentioned in the following days/weeks/month as part of DevTools-Fission-M1 goal, which current forecast announces Dec 20th as due date.
The following M2 goal is going to be about the "real fission". We haven't discussed it yet, but it is probably going to be about turning fission ON by default.

Comment 7

[Victoria Wang [:victoria]]

Thanks for all the info, Alex! I'll hold off then, but will be watching this bug :)