Closed Bug 1055279 Opened 7 years ago Closed 7 years ago

Bring up developer tools by default when I select a runtime app / tab

Categories

(DevTools Graveyard :: WebIDE, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 35

People

(Reporter: kgrandon, Assigned: jryans)

References

Details

(Whiteboard: [status:landedon])

Attachments

(1 file, 4 obsolete files)

Right now you have to click the tiny "debug" button to bring up the devtools after selecting an app. It's a small target, and does not really look like a devtool button at all. This page is also not really useful, and it's much slower to work with WebIDE than the app manager.

To streamline things, the devtools should start immediately if I click on an app.
I've filed bug 1055340 about make the debug / pause button more obvious, so let's handle that piece over there.

I guess you mean more specifically: after selecting an app already installed on device (i.e. not one you're also working on as a project you want to install), open the toolbox immediately.

This sort of makes sense to me, but only for installed apps, since there are other obvious actions to perform.  For projects you are actively editing, I wouldn't want to do this by default.  And given that, it seems confusing for one type of app to auto-debug, while the other does not, as that could end up being more confusing overall.

Also, please clarify why you perceive it to be "much slower" to work with WebIDE.  If it's separate from this issue, file separate bug(s).  I believe most actions take a similar number of clicks to perform, so I am not entirely sure what you mean.
Flags: needinfo?(kgrandon)
I think the main issue is that from the app manager we could select "Debug" and open the devtools directly. In the WebIDE we have to select an app from the dropdown, then click another button.

It's much slower than the app manager, because of a number of reasons. Perhaps these could all be individual bugs:
1 - Too many steps to get into devtools on a running app.
2 - 'Ctrl + F' to find an app by name for example does not work, making it difficult to find the app in the first place.
3 - Not aware of an about:webide or shortcut to open it up.
Flags: needinfo?(kgrandon)
That's quite helpful, thanks!

I've filed bug 1055347 and bug 1055348 for parts 2 and 3.

For part 1 (this bug), does it help at all that "Play" and "Debug" have keyboard shortcuts (see the "Project" menu in the menu bar)?
Flags: needinfo?(kgrandon)
(In reply to J. Ryan Stinnett [:jryans] from comment #3)
> For part 1 (this bug), does it help at all that "Play" and "Debug" have
> keyboard shortcuts (see the "Project" menu in the menu bar)?

It's helpful, but I suppose to make this a really effective tool, we'd need to make selecting an debugging a running app just as prominent as selecting an app currently is. I think that's why the app-manager having multiple options front and center was useful.

It was one step to go into the devtools, instead of three. Currently you have to select the dropdown, select the app, then tap the debug option. With the single manager you could press a single button and land in devtools.
Flags: needinfo?(kgrandon)
(In reply to Kevin Grandon :kgrandon from comment #4)
> (In reply to J. Ryan Stinnett [:jryans] from comment #3)
> > For part 1 (this bug), does it help at all that "Play" and "Debug" have
> > keyboard shortcuts (see the "Project" menu in the menu bar)?
> 
> It's helpful, but I suppose to make this a really effective tool, we'd need
> to make selecting an debugging a running app just as prominent as selecting
> an app currently is. I think that's why the app-manager having multiple
> options front and center was useful.
> 
> It was one step to go into the devtools, instead of three. Currently you
> have to select the dropdown, select the app, then tap the debug option. With
> the single manager you could press a single button and land in devtools.

Is your use case that you are typically choosing the same device-only / runtime app to debug?  We could make it so that the runtime app choice persists, even after closing and reopening WebIDE (currently it stays during one session only).

Or are you instead frequently working with many different apps?
Flags: needinfo?(kgrandon)
We do both. I think it needs to be faster to jump into the devtools if you are just debugging one app, or multiple. I do feel that third parties will typically focus on one app at a time though, and gaia developers would more likely focus on multiple.
Flags: needinfo?(kgrandon)
Based on the feedback of this bug and various comments I received about WebIDE
from gaia devs, here is a serie of quick tweaks to ease using WebIDE
while working on gaia.

A first one to show the toolbox for runtime apps.
Another one to save the selected runtime in order to automatically
reconnect to it.
And a last one to save the current project in order to automatically
reselect it, if available in the newly connected runtime.
Comment on attachment 8484284 [details] [diff] [review]
Show toolbox when selecting runtime apps in WebIDE. r=jryans

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

Let's start with this one, which seems to be the main request behind this bug.
I'm not really satisfied with this patch but don't see how to do differently.
We have to hack something within app-manager.js, as we have to wait for runRuntimeApp() to finish
before trying to open the toolbox. But we have to call some code from webide.js to open the toolbox.
I introduce a "open-toolbox" event... but that looks weird. May be we can dispatch a more
generic one, like "app/project-is-ready/debuggable"?

If you have some early feedback for the two other patches, that would be welcomed!
Also I just want to see this bug moving forward without necessarely having to work on it,
so feel free to pick it up if you have some cycle and see how to easily fix those things ;)
Attachment #8484284 - Flags: feedback?(jryans)
I hope to look at this tomorrow.
(In reply to Alexandre Poirot [:ochameau] from comment #9)
> Created attachment 8484286 [details] [diff] [review]
> Remember last selected project in WebIDE
> 
> And a last one to save the current project in order to automatically
> reselect it, if available in the newly connected runtime.

To keep this bug more focused, please move this patch to bug 1055666.
(In reply to Alexandre Poirot [:ochameau] from comment #8)
> Created attachment 8484285 [details] [diff] [review]
> Remember last selected runtime in WebIDE
> 
> Another one to save the selected runtime in order to automatically
> reconnect to it.

...and please move this one to bug 1045660.
Comment on attachment 8484284 [details] [diff] [review]
Show toolbox when selecting runtime apps in WebIDE. r=jryans

We'll this is basically what we want, but I'd keep the logic in webide myself.

Basically, no solution will feel great, since projects are such a mess right now.

I'll take this off your hands and polish this up tomorrow.
Attachment #8484284 - Flags: feedback?(jryans)
Assignee: nobody → jryans
Status: NEW → ASSIGNED
Okay, I moved the other patches to the related bugs.
Attachment #8487485 - Flags: review?(paul) → review+
Updating this to also auto-open for tabs.

Basically, for anything that's not an editable app, we might as well debug immediately, since that's all you can do anyway.
Summary: Bring up developer tools by default when I select an app → Bring up developer tools by default when I select a runtime app / tab
https://hg.mozilla.org/integration/fx-team/rev/8ab67eccf920
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [status:inflight] → [status:inflight][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/8ab67eccf920
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [status:inflight][fixed-in-fx-team] → [status:inflight]
Target Milestone: --- → Firefox 35
Whiteboard: [status:inflight] → [status:landedon]
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.