Now that a few local targets are being listed in about:debugging, we should display remote devices as well, and allow a user to connect to them in order to show their debuggable targets. We should show: - Devices accessible via USB (Firefox OS, Fennec, Chrome/iOS webviews, ...) - Devices accessible over Wi-Fi - Devices accessible through Firefox Accounts? (this would need fxaccount work) - Installed Simulators - Other browsers like Chrome, Safari, ... Along with a "Connect" or "Launch" button. Once that button is clicked, Firefox should connect to that device, and request a list of all its debuggable targets, e.g.: - Open tabs - Apps - Add-ons - Workers - etc.

Ryan, this work-in-progress patch attempts to list remote devices and their targets, and I'd love some early feedback. What works: - Detecting USB/Wi-Fi devices and Simulators. - Connecting to them, and listing their tabs. What doesn't: - Configuring the device (no buttons for Settings, Preferences, Screenshot...). - Listing remote targets other than Tabs (e.g. Apps, Add-ons...). - Listing other Remote Runtimes (Chrome, Safari, IP+port, etc). - Clicking on "Debug" next to a tab (no toolbox shows up, browserconsole shows [1]). [1] "toolbox-highlighter-utils.js:34 Error: Missing or invalid toolbox passed to getHighlighterUtils"

The Remote Devices panel is already feeling packed and confusing (see screenshot), and I'd like to add even more information and controls. Some things I'd like to add that are not in the screenshot yet: - Basic info about a device (e.g. OS version, if Developer Mode is enabled, etc). - Ways to display more info about a device (similar to "Runtime Info" and "Permissions Table" in WebIDE's right sidebar). - Controls to configure a device (e.g. change its Settings/Preferences, configure simulation options, etc). Other projects with similar features: - WebIDE's right sidebar (and "Runtime" menu) is for remote devices & connection management. - Google Chrome's about:inspect has a similar "Devices" panel for debugging things on remote devices. Helen, do you have ideas how I could improve this panel while adding the additional features listed above?

Devices selection is orthogonal to everything else. My vision of about:debugging is that, by default, it targets the things available in your Firefox instance (service workers, addons and such). But then, when it comes to devices, we select one, and the whole about:debugging page switch its context to the selected device. So, the device panel should be special, this is different from Workers or Addons. Once we select a device, the existing Workers and Addons panels are going to show the Device ones and no longer the browser ones. So if you want to show tabs, you would implement a new Tabs panel, like the others. May be some panels will only be displayed for remotes like tabs. This vision is based on all the efforts we made to come up with the Remote Devtools Protocol (RDP). One you connect to a target, which can be firefox or a device and then select a context to debug (tab, app, addon), you then can expose the exact same feature, using the exact same code, no matter what target/context you selected. If you keep going with your current approach, you are going to reimplement all panels within device and make the UI even more complex.

Comment on attachment 8676489 [details] [diff] [review] [WIP] List remote devices and their targets in about:debugging. Review of attachment 8676489 [details] [diff] [review]: ----------------------------------------------------------------- Looks good codewise. ::: devtools/client/aboutdebugging/components/runtimes.js @@ +33,5 @@ > + }, > + > + componentDidMount() { > + RuntimeScanners.on("runtime-list-updated", this.update); > + RuntimeScanners.enable(); You should check for RuntimeScanners.enabled to call this.update() immediately if the scanners are already up and running (when you reload about:debugging) ::: devtools/client/aboutdebugging/components/target.js @@ +50,5 @@ > + chrome: false, > + form: target.form > + }); > + console.log("tab", target, "target", t); > + gDevTools.showToolbox(t.value, null, Toolbox.HostType.WINDOW); (In reply to Jan Keromnes [:janx] from comment #1) > - Clicking on "Debug" next to a tab (no toolbox shows up, browserconsole > shows [1]). > > [1] "toolbox-highlighter-utils.js:34 Error: Missing or invalid toolbox > passed to getHighlighterUtils" The issue is here. forRemoteTab returns a promise whereas showToolbox expects a target. You should do something like: t.then(target => { gDevTools.showToolbox(target, ...) }); Also, with the patch I'm about to attach to the bug, you could pass HostType.BOTTOM and prevent having windows everywhere ;)

Cool! Thanks Alex :)

Comment on attachment 8676489 [details] [diff] [review] [WIP] List remote devices and their targets in about:debugging. Review of attachment 8676489 [details] [diff] [review]: ----------------------------------------------------------------- My feedback is the same as Alex overall: let's avoid rebuilding a nested UX just for devices. Instead, re-target the about:debugging page to show what's on the device, instead of local Firefox. We should make sure it's always clear when the device connection is active, perhaps with a thin, persistent bar across the top of the page "You are currently viewing debuggable things from your Firefox OS Flame <Disconnect>" or something, that's just one idea. It should be obvious, though. An alternative would be to show a merged view of both local and the device at the same level... but that's probably too mind-blowing / confusing. However it's done, the main goal is for the left panel's categories (workers, tabs, apps, ...) to reflect the targeted thing, which can be the device once you connect to it. Continuing the theme of meaningful URLs, I would love for the URL to change once you are connected to a device. Then, you could bookmark that as a way to fast-reconnect next time. That solves the issues we have with WebIDE's auto-reconnect that not everyone wants: with about:debugging, it becomes an explicit choice by visiting the URL for that device.

Straight rebase, review comments still not addressed. https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a960c77df1d

Helen, here is where you can find an OSX build that includes the new "Devices" tab (and a few other things): http://archive.mozilla.org/pub/firefox/try-builds/janx@linux.com-6a960c77df1df5a592df56c18a366d826112bf4f/try-macosx64/firefox-45.0a1.en-US.mac.dmg

I've added a couple of sketches based on what janx and ochameau were discussing; for simplicity's sake I thought it would be helpful to see both drawn up. I think that both approaches have their advantages and disadvantages: If we switch the entire context of about:debugging, the drop-down menu or whatever handles that could get a little unwieldy in theory. I like that this allows us to have a lot of room for any individual runtime (whenever you switch contexts you could have its Runtime Info, Tabs, Permissions, whatever else that's relevant already expanded). If we have the four categories that janx lists above, we lose that room for individual runtimes but the categories might be considered more intuitive. In all honesty I've been thinking about this for a bit and still don't feel super strongly about either solution from a UX standpoint, so I'm deferring to janx for the brains on this one.

A few random thoughts: * I am somewhat wary of a runtime dropdown (mentioned in option 1) if that is meant to be how you initially pick a runtime to connect to * We went to a lot of trouble with WebIDE recently to move **away** from the popup type runtime list to having them directly on the page based on user feedback that the popup was (a) too hidden for new users and (b) an extra click to achieve the same thing, and people seem to really hate extra clicks at least among FxOS devs * A dropdown seems okay if it's for switching after initial connection, however. * I like that option 1 highlights explicitly which runtime you are looking at in the header * What I have in my head looks similar to the WIP screenshot :janx attached, but connecting to a device would either: * Change the context of the current about:debugging tab to focus on the new remote runtime **OR** * Open a new about:debugging tab with for the new remote runtime * Either way, I think it's a "killer feature" that the URL changes to reflect the new runtime for bookmarking and faster launching in the future * Assuming we have some URL that connects directly to a remote device, it seems strange to display all possible runtimes, like in option 2. Since a runtime is already chosen in this case, I would expect the main sidebar on the left to contain key sections for that runtime, like Prefs, Settings, Tabs, etc. The page should definitely state the connected runtime clearly, like in option 1. I can try to assemble my thoughts into a mockup, if that would be helpful.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #13) > * A dropdown seems okay if it's for switching after initial connection, > however. Yeah; I wonder if there's a way to get the benefits of option #1 (explicitly stating the runtime in the header, having space for the permissions/runtime tables) without the awkwardness of a dropdown. > * I like that option 1 highlights explicitly which runtime you are looking > at in the header > * What I have in my head looks similar to the WIP screenshot :janx attached, > but connecting to a device would either: > * Change the context of the current about:debugging tab to focus on the > new remote runtime **OR** > * Open a new about:debugging tab with for the new remote runtime > * Either way, I think it's a "killer feature" that the URL changes to > reflect the new runtime for bookmarking and faster launching in the future I think I would prefer the first option out of these two, but I'd love to know what janx is thinking. I think that it would also be helpful if the tab title had the name of the runtime in addition to "about:debugging"; sorry if you've already implemented this and I just didn't notice! > * Assuming we have some URL that connects directly to a remote device, it > seems strange to display all possible runtimes, like in option 2. Since a > runtime is already chosen in this case, I would expect the main sidebar on > the left to contain key sections for that runtime, like Prefs, Settings, > Tabs, etc. The page should definitely state the connected runtime clearly, > like in option 1. > > I can try to assemble my thoughts into a mockup, if that would be helpful. If you'd be willing to draw up some sketches I imagine that would be pretty helpful! After your comment I definitely think I'm still wrapping my head around the problem, honestly.

Setting ni? to make some mockups. I'm off tomorrow, but I intend to do this sometime this week.

I've tried to illustrate the key navigation concepts I'd like to see in a Balsamiq mockup. Hopefully it's obvious from Balsamiq's general style, but there's absolutely no visual details (colors, fonts, etc.) defined in my mockup: I'm sure Helen and Jan can work out these bits as needed! :) There are some comments inline in the mockup, but here's a summary: * The "local" runtime that is desktop Firefox tells you about devices it can see * Accessing a new runtime means you get a new tab for exploring it * Debugging a target (like an app, tab, etc.) means you get a new tab with a toolbox * Persistent notification bar ensures you always know what you are seeing * Every state has a real URL you can bookmark and jump back to any time in the future

No one's commented so ~~I will~~ I'm a fan of your mockup, Ryan. Makes sense to me. Jan, maybe you can comment on what you still think is missing/if this is good to you?

I don't know about the fact that debugging a target opens a new tab, but I'm all in for the overall navigation.

(In reply to Alexandre Poirot [:ochameau] from comment #18) > I don't know about the fact that debugging a target opens a new tab, but I'm > all in for the overall navigation. I think it could be quite powerful, especially for FxOS. As in, you could debug say Music in one tab and System in the other, if you are working on something that integrates between the two apps. It's probably not a common case, though. Overall, what I like about defaulting to "just a open tab" is it gives the user more control over the exact UX: they can move it to a separate window if they wish to see two things at once, they can open multiple tabs at once, etc. None of these can be done in WebIDE, since there is only one window to work with.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #19) > (In reply to Alexandre Poirot [:ochameau] from comment #18) > > I don't know about the fact that debugging a target opens a new tab, but I'm > > all in for the overall navigation. > > I think it could be quite powerful, especially for FxOS. As in, you could > debug say Music in one tab and System in the other, if you are working on > something that integrates between the two apps. It's probably not a common > case, though. > > Overall, what I like about defaulting to "just a open tab" is it gives the > user more control over the exact UX: they can move it to a separate window > if they wish to see two things at once, they can open multiple tabs at once, > etc. None of these can be done in WebIDE, since there is only one window to > work with. I'm not all up against that, but I would like to see it live to make my opinion. Opening the toolbox in the same tab doesn't prevent supporting magic URLs. You could still open two about:debugging tabs and debug multiple apps. If we use a <a> link for the debug action, it could be as a website link and be opened in a new tab on-demand. Note that it should be easy to switch to one way or another once we get there.

We should aim for a v1 of this for the next release (Firefox Developer Edition 48).

(Restoring Helen's needinfo on myself from comment 17, so that I don't forget to comment on the amazing and super useful UX concepts for this bug.)

I'll take another stab at this.

Helen and Ryan, thanks again for your great UX concepts! I really liked your ideas, and here is how I imagine implementing them. (Marking the "[WIP] Screenshot" and "option-2.jpg" as obsolete, option-2 because I was the only proponent of it and you've convinced me otherwise.) What I liked about Helen's "option-1.jpg": - Light "connected" indicator - Runtime name in left menu above target types - Dedicated runtime panel with name and version in first line What I liked about Ryan's "Device Navigation Concepts": - Title including runtime name and target type - Persistent runtime name in the page - Dedicated remote runtimes panel, with buttons that open new tabs - URL that specifies which runtime to connect to What I meant to convey in my sketch: - Both title and left menu clearly indicate what you're debugging and on which runtime - New suggested panels: "runtime" (Helen's runtime panel) and "connect" (Ryan's runtime panel) - I suggest listing processes and adding Browser(Content)Toolbox buttons to the runtime panel - ("Disconnect" button is not really useful) - ("change/#connect" link should probably be renamed / replaced by an icon)

Comment on attachment 8738254 [details] Jan does UX Helen and Ryan, flagging you for feedback.

Comment on attachment 8738254 [details] Jan does UX I love the title of this, this is my favorite! title: "Debugging <TARGET-TYPE>..." I think you can cut "with Firefox Developer Tools". It'll get cut by the tab anyway, I think. Tabs/Pages/Apps: I think if we come up with a better name, the #hash will be more obvious. You might be able to get away with just "Apps", but I'm not sure. Content Process [num]: Are these technically debugging workers? Should we just have the name of the worker?... (Wait, was that your plan already?)

Comment on attachment 8738254 [details] Jan does UX "Processes" may live in its own panel, like Addons, Tabs and Workers "Tabs/Pages/Apps" Tabs. We plan to deprecate apps support, if it's not already done. Then I imagine "Tabs" is more commonly used than "Pages". If we come up with Apps again, or anything similar it would justify its own new dedicated panel. Otherwise, if we start using query parameters, may be using a query parameter for the selected panel would be clearer? about:debugging?runtime=local&panel=addons ? Or anything more or less similar.

Comment on attachment 8738254 [details] Jan does UX I'm not sure you want to merge tabs and apps together like that, so maybe have separate entries for tabs vs. apps. (I am also not sure how much we care about apps for about:debugging?) I agree with Alex that we should think carefully about what's in the query param vs. hash. I guess right now you're using query param for the runtime since there's an entire new page per runtime, while the hash is used for tab since they happen "in page"? Also, how do you reach this view if you start from about:debugging?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29) > Also, how do you reach this view if you start from about:debugging? History API? https://developer.mozilla.org/en-US/docs/Web/API/History I'm thinking about using that for about:devtools-toolbox. At least for the new "panel" attribute, to reflect panel change in the URL.

(In reply to Alexandre Poirot [:ochameau] from comment #30) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29) > > Also, how do you reach this view if you start from about:debugging? > > History API? > https://developer.mozilla.org/en-US/docs/Web/API/History > I'm thinking about using that for about:devtools-toolbox. > At least for the new "panel" attribute, to reflect panel change in the URL. What I mean is if I go to regular "about:debugging", what do I click on or do to get this view is for a particular runtime? Is there a list of runtimes? Does the page default to being connected to local Firefox, and you click "change" within that page to reach a different one?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #31) > What I mean is if I go to regular "about:debugging", what do I click on or > do to get this view is for a particular runtime? Is there a list of > runtimes? Does the page default to being connected to local Firefox, and > you click "change" within that page to reach a different one? The idea I was trying to convey in https://bug1212802.bmoattachments.org/attachment.cgi?id=8738254 is this: 1. When you navigate to regular "about:debugging", it connects by default to local Firefox (as it is today) 2. You see that it is connected to "Local Firefox" at the top of the left menu (should be always visible) 3. The "change" link or button (or better UI thing) opens a panel listing all available remote runtimes 4. In the view from 3., clicking on "Connect" (or "Explore" or similar) next to a runtime opens a URL like "about:debugging?runtime=whatyouchose" (in place, or in a new tab) Clicking in 4. leads to 1. but connected to whatever runtime you specified instead of the default "Local Firefox". Ryan, what do you think about these ideas?

(In reply to Jan Keromnes [:janx] (away until June 2) from comment #32) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #31) > > What I mean is if I go to regular "about:debugging", what do I click on or > > do to get this view is for a particular runtime? Is there a list of > > runtimes? Does the page default to being connected to local Firefox, and > > you click "change" within that page to reach a different one? > > The idea I was trying to convey in > https://bug1212802.bmoattachments.org/attachment.cgi?id=8738254 is this: > > 1. When you navigate to regular "about:debugging", it connects by default to > local Firefox (as it is today) > 2. You see that it is connected to "Local Firefox" at the top of the left > menu (should be always visible) > 3. The "change" link or button (or better UI thing) opens a panel listing > all available remote runtimes > 4. In the view from 3., clicking on "Connect" (or "Explore" or similar) next > to a runtime opens a URL like "about:debugging?runtime=whatyouchose" (in > place, or in a new tab) > > Clicking in 4. leads to 1. but connected to whatever runtime you specified > instead of the default "Local Firefox". > > Ryan, what do you think about these ideas? (Sorry for the delay!) Okay, I think this makes sense! I think the key point for me is that we'll get a URL that targets a specific runtime, and can be saved, bookmarked, etc. Also, it sounds like UI of about:debugging would basically look the same for a local runtime vs. remote runtime. It just happens that "about:debugging" will go to the local one. So if I load "about:debugging?runtime=fennec_on_my_phone" (using whatever the appropriate value of runtime is for that situation), would the page auto-connect on page load to that runtime?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #33) > Okay, I think this makes sense! I think the key point for me is that we'll > get a URL that targets a specific runtime, and can be saved, bookmarked, > etc. Stable runtime-specific URLs are indeed a central component of this design. > Also, it sounds like UI of about:debugging would basically look the > same for a local runtime vs. remote runtime. It just happens that > "about:debugging" will go to the local one. That's correct, when not specified via a query parameter (i.e. "about:debugging" instead of "about:debugging?runtime=local") the runtime defaults to local runtime, keeping current about:debugging behavior unchanged. > So if I load "about:debugging?runtime=fennec_on_my_phone" (using whatever > the appropriate value of runtime is for that situation), would the page > auto-connect on page load to that runtime? Yes, that's the plan. We'll probably need some bit of UI to show connection state (e.g. connecting, failed, etc), with as much helpful information as we can get for failure cases (so that users can file any "Can't connect to runtime X" bugs with as many details as possible).

My understanding is that :janx is not working on this currently.