Bug to track the Developer tools for the new settings UI rework. This includes remote debugging and auto updater (for nightly/aurora builds).

This should toggle the pref "devtools.debugger.remote-enabled" to true, and then prompt for restart. Ideally, there would also be some instructions for how to use remote-debugging, like mfinkle's blog post (http://starkravingfinkle.org/blog/2012/08/firefox-for-android-remote-debugging-is-here/). Perhaps a "Learn more" or "how to" link that displays a dialog or opens up a new nested screen. Some UI questions here, because the usual text area probably does not provide enough space.

We could look at b2g "developer tools" settings as well. There might be more we can enable in the content area for Web Devs.

Screenshot of some possible dev tools we might want to eventually include. (Not pictured: "Wi-Fi output in adb", "Console Enabled") I need to investigate to see if any of these other than remote debugging are available on Android, and if so, how to enable them.

Screenshot with most of the dev tooling turned on - some of this might look a little scary to basic users.

I just realized that it would be great to get this into 24; this is starting a little late, so I thought I'd see if you have any thoughts about UI for this? (Sorry, Ian! And bug 872329 should land today or tomorrow.) My thoughts are that we could nest it one layer down, perhaps under Display > "Advanced" (category) > Developer Tools, which will go to its own screen. We could also stick somewhere it under "Mozilla," though I guess it doesn't really fit particularly well into either category. (Top level category is probably foot-gun for unsuspecting basic users.) Enabling debugging also requires some extra work on the user's part (see mfinkle's blog posts at [1] and [2]), such as restarting Fennec. We'll probably want to do something like pop up a (unfortunately long) dialog with some basic instructions, and a "Restart" button (since we removed the "Quit" menu item). Not sure if linking to the blog posts is even a good idea. [1] http://starkravingfinkle.org/blog/2012/08/firefox-for-android-remote-debugging-is-here/ [2] http://starkravingfinkle.org/blog/2012/10/firefox-for-android-remote-web-console-is-here/

Apks for the different versions are here: http://people.mozilla.com/~liuche/bug-871866/ There are several things that we need to consider for the UI. - summary string (if any) describing "Remote Debugging" - some way to restart FF to make devtools option stick - linking to instructions (which also need to be localized!) which also contains some complexity ...because the tricky part is enabling remote debugging - it's not as simple as clicking the checkbox. We also need provide the instructions, by a) linking to an external Mozilla page, b) writing a screen to explain in native, c) link to an external Mozilla page inside of an iframe (?). Basic instructions: 1. Connect phone to computer using USB. 2. Enable remote debugging on Desktop version (about:config => set devtools.debugger.remote-enabled to true). Restart Desktop version. 3. Enable remote debugging on phone. Restart. - we need to add a "Restart" button 4. Run "adb forward tcp:6000 tcp:6000" to start sending phone debug output to the Desktop version. - To kill this forwarding, kill adb and restart 5. Enter into remote debug mode by going to "Tools > Web Developer > Connect...". - this probably varies based on platform, and also based on FF version (FF15 has a different path) 6. Accept defaults (port 6000), wait for connection. - bug 887506 causes a visual timeout on desktop, even though the connection works. 7. Reminder: need to re-forward port (from step 6) any time device is restarted. Anyways, take a look at the apks and screenshots, and let me know what you think.

I think I favor Option 3 structure (top-level Advanced > Dev Tools)

(In reply to Mark Finkle (:mfinkle) from comment #11) > I think I favor Option 3 structure (top-level Advanced > Dev Tools) +1, that works for me. As for where to keep the instructions, it would be great to try to keep it within the Settings UI if we can, to make the user flow more consistent.

Alternatively, I could not do all this register/unregistering on onPause/onResume - there will be a slight overhead to resolving all the intents to "bring activity forward" but it's very possible that outweighs all the accesses to the CopyOnWriteArrayList in the util/EventDispatcher.

Let me know if you think these look weird...

There might be some value to popping up a Toast message when you enable remote debugging, although it should be obvious that you need to initiate remote debugging from a remote device. These [1] are the docs for remote debugging, and they seem pretty clear, so perhaps toast isn't needed.

Chenxia, just want to make sure I understand what I'm looking at here -- is the idea here that we are landing the remote debugging pref first, and then following up with the instructions on getting started? Or does turning on remote debugging here automatically enter you into that 'getting started' flow? If it's the former, this looks good. If it's the latter, I tend to prefer what you proposed earlier in the bug, in comment 10

Comment on attachment 776835 [details] [diff] [review] Part 1: Strings v1 Moving to bug 888533.

Comment on attachment 776837 [details] [diff] [review] Part 3: Surface browser activity + dialog (Wes, I'm going to make Lucas review this since you're at a work week.)

Thanks for the feedback Ian - I actually posted this in the wrong bug (should be minimum v1 for remote debugging) but what do you think about the MDN link? Would that be sufficient to link to? I can see the value in being explicit about how to set up remote debugging - a different string from "Getting started" would be better though, because once you click whatever information link we put there, you'll be removed from the Settings flow and have to launch settings again. Maybe "More information"?

nglayout.debug.paint_flashing controls display of page paints, but seems to be kind of buggy (grid pattern in paints). This is easily enabled, but might not be worth enabling if it doesn't work very well.

(In reply to Chenxia Liu [:liuche] from comment #25) > Created attachment 784124 [details] > Screenshot: layout paint debug pref (slightly buggy) > > nglayout.debug.paint_flashing controls display of page paints, but seems to > be kind of buggy (grid pattern in paints). This is easily enabled, but might > not be worth enabling if it doesn't work very well. I wonder if the grid is due to the Tile System used to paint the content. This might be coming to FirefoxOS soon too. Will that also show the tiles when paint flashing?

Ah, you might be correct that it's not actually broken, and paints in tiles - I don't really understand the color distribution of the tiles though, so I'd be interested to know what those signify and why they're very different.

Paint flashing is explained in the second paragraph here: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance#Diagnosing_performance_problems

This will eventually come to FirefoxOS - I guess we might want to set the colour in some other way perhaps so that the tile boundaries don't show up, though I often find seeing the boundaries quite useful. That should probably be a different feature though. As for the colour, there is no significance to it, it's random - just a different colour means a different draw call did the painting.

I'm closing this bug, since all the dependent bugs are fixed.