Tablet browser with integrated developer tools?

[Claus Reinke]

Todays tablets have the hardware, the screens, and the (external)
keyboards to serve as mobile development platforms. So I was
surprised to see that the default Nexus 7 browser (chrome) only
offers remote debugging, as if a tablet was just a big smartphone.

Are there any tablet browsers with integrated developer tools,
or are we back to Firebug Lite and friends? Do you use your
tablet for mobile development at all?

Claus
http://clausreinke.github.com/

[Anton Kovalyov]

(I work on Firefox Developer Tools)

Firefox doesn't have any kind of integrated devtools in our Android version. I heard there are some people that are vaguely interested so there are no plans *not* to. That said, there aren't any immediate or speculative plans to implement that either.

Anton

Anton

--
http://clausreinke.github.com/js-tools/resources.html - tool information
http://groups.google.com/group/js-tools - mailing list information

[Jake Verbaten]

As a developer i'm not that interested in the debugger.

I'm more interested in being able to peek at the console to see console.error calls and thrown exceptions.

Having a way to inspect the console would be a big win.

[John J Barton]

For Chrome browser, the way you see the console is with the debugger.

jjb

[Anton Kovalyov]

You mean, being able to peek at the console *from the tablet itself?* Because otherwise you can use Firefox console remotely: http://starkravingfinkle.org/blog/2012/10/firefox-for-android-remote-web-console-is-here/

Anton

Anton

[Scott Elcomb]

On Wed, Dec 5, 2012 at 2:44 PM, Jake Verbaten <ray...@gmail.com> wrote:
> As a developer i'm not that interested in the debugger.
>
> I'm more interested in being able to peek at the console to see
> console.error calls and thrown exceptions.
>
> Having a way to inspect the console would be a big win.

+1 Not having a console in mobile browsers is a serious pain in the
/dev/null. AFAIK, the only mobile browser that includes a console is
Safari.

--
Scott Elcomb
@psema4 on Twitter / Identi.ca / Github & more

Atomic OS: Self Contained Microsystems
http://code.google.com/p/atomos/

Member of the Pirate Party of Canada
http://www.pirateparty.ca/

[Scott Elcomb]

On Wed, Dec 5, 2012 at 2:49 PM, Anton Kovalyov <an...@kovalyov.net> wrote:
> You mean, being able to peek at the console *from the tablet itself?*
> Because otherwise you can use Firefox console remotely:
> http://starkravingfinkle.org/blog/2012/10/firefox-for-android-remote-web-console-is-here/

The remote console is better than none. Speaking for myself, I spend
more than 20 hours commuting each week. I picked up a tablet
specifically to work during my train rides however I discovered that
I'll need a second tablet to debug with - which kind of defeated the
purpose.

Until consoles are integrated into mobile browsers, I'll just be using
my tablet for email, twitter and games.

[Ben Combee]

I see quite a bit of benefit from some simple debug tools on tablet devices.  Having a "console" tab would be really useful, one with the ability to evaluate expressions.  I'm not sure step-by-step debugging is something I'd want to do, but being able to see some debug output from a webapp that doesn't disturb the main DOM would be really nice.  The remote debuggers are very useful, but it's often a pain to configure that as part of a larger QA process.

[Patrick Mueller]

On Wed, Dec 5, 2012 at 2:50 PM, Scott Elcomb <pse...@gmail.com> wrote:

+1 Not having a console in mobile browsers is a serious pain in the

/dev/null.  AFAIK, the only mobile browser that includes a console is
Safari.

I would claim the "console" in mobile Safari is a "you got what you asked for".  Sure, it works.  But it's a royal PITA.  I never use it.

 

--
Patrick Mueller
http://muellerware.org

[Panagiotis Astithas]

The two biggest impediments to adding developer tools to mobile browsers in my view are (a) the inevitable increase in app size, which is terribly important in these devices, and (b) the need to rewrite the tools to use touch input and work well on small screen sizes. I think we need to limit our focus on specific use cases and rethink the way we create these tools, if we are to ship them with mobile browsers.

On the plus side, remote debugging and inspection is supported broadly by now, and will undoubtedly only improve in the future.

--
Panagiotis Astithas
http://astithas.com
Firefox DevTooler

[Mikhail Naganov]

(I work on Chrome for Android)

I actually tried using Chrome DevTools on a tablet (10" Xoom), and the
experience was just horrible -- the UI is simply not optimized for
touch input. I agree that debugger's UI needs to be rethinked from the
ground up to be used from mobile devices. For anyone having time and
courage to try that -- you can download and build Chromium's Content
Shell for Android and change one line to use a TCP socket for remote
debugging (instead of linux abstract socket), so you can connect to
the debuggee from a browser running on the device.

For answering quick questions like "what is the reported clientWidth
for the body element" one can use "javascript:" protocol for
evaluating things on the page. E.g. try to type
"javascript:alert(document.body.clientWidth)".

[Patrick Mueller]

I'm a fan of remote debugging for mobile, until we have the capability of having '2nd monitors' for our mobile devices, or the screen real estate becomes so large you can run apps in a windowed desktop kind of environment.  As long as the apps on our mobile devices are full screen, I'll stick to a remote debugger.

An interesting twist on this though, is being able to use your mobile device as a debug tool for other debuggers.  Make use of the touch interface to provide an input (and output) area to drive other debuggers.  In the same way that folks use "virtual keyboards" or other midi/osc controllers on their mobile device to control their desktop music creation software. 

 

[Claus Reinke]

> The two biggest impediments to adding developer tools to mobile browsers in
> my view are (a) the inevitable increase in app size, which is terribly
> important in these devices, and (b) the need to rewrite the tools to use
> touch input and work well on small screen sizes. I think we need to limit
> our focus on specific use cases and rethink the way we create these tools,
> if we are to ship them with mobile browsers.

(a) do the developer tools as an extension
(b) as a first approximation: just make sure everything can be
keyboard-controlled

Interested developers could then install the extension and use a
wireless keyboard. Non-developers wouldn't be affected.

Claus

[Claus Reinke]

> For answering quick questions like "what is the reported clientWidth
> for the body element" one can use "javascript:" protocol for
> evaluating things on the page. E.g. try to type
> "javascript:alert(document.body.clientWidth)".

Then the next step is a bookmarklet that adds a div to the page
and redirects console output to that div, and before we know it,
we have reinvented firebug (at least in the lite, cross-browser
version).

http://getfirebug.com/firebuglite#Stable

Has anyone tried that on a tablet yet?

Claus

[Scott Elcomb]

It's been rather a while since I tried. Trying again, it works in
Firefox for Android (4.0.3).

Looks like it's broken in Chrome (no way to create the bookmarklet and
although the FBL UI pops up when the getfirebug.com page loads, it
appears to be completely unresponsive). FBL also doesn't work in the
default Android browser (no way to create the bookmarklet, UI does not
pop up as in Chrome).