Kobo Touch HTML/JavaScript support?

[dgatwood]

I recently attempted to use the Nook Touch web browser for a project and found that it was way too slow and hopelessly broken (no support for onmouseup/onmousedown, no support for touch events, etc.).

To avoid these sorts of problems with my next hardware purchase, I wrote up a trivial test page that tests the core HTML/JavaScript functionality that I need for this project.

Could somebody with a Kobo Touch please go to the following web page, follow the instructions, and post back your results? Thanks.

http://www.gatwood.net/runtests.html

[dmacmart]

Interesting. I tried the Kobo Touch, Vox, and also my iPad. Since my husband is currently reading his KT I only ran it once there but multiple on other platforms

All passed onclick
All failed first onmousedown (with time of 0.0)*
KT and Vox failed the second onmousedown with time of 0.0 (iPad sometimes passed; in that case, 3rd message was labelled ontouchstart - but mostly failed)
Latency between 0.9 (iPad) and 1.4 (KT)

(1)On the KT, the timer was wildly slow - countdown seconds were not real seconds
On the iPad, there are two latency times printed usually 0.4 seconds apart

(2)On the Vox, the long-press put the cursor into text-copy mode even for a button
Sometimes the onmousedown failure printed times, sometimes not

[Joe563]

Originally Posted by dgatwood

I recently attempted to use the Nook Touch web browser for a project and found that it was way too slow and hopelessly broken (no support for onmouseup/onmousedown, no support for touch events, etc.).

To avoid these sorts of problems with my next hardware purchase, I wrote up a trivial test page that tests the core HTML/JavaScript functionality that I need for this project.

Could somebody with a Kobo Touch please go to the following web page, follow the instructions, and post back your results? Thanks.

http://www.gatwood.net/runtests.html

I ran the tests on both my Kobo Touch and my Sony PRS-T1. Here are the results:
Kobo Touch Sony PRS-T1
onclick: pass pass
onmousedown: fail(time = 0.0) fail(time = 0.0)
ontouchstart: fail pass
latency: 1.2 seconds 1.2 seconds

The only difference in the test results for the two devices is for ontouchstart.

[dgatwood]

Ah. I forgot to add -webkit-user-select: none on the body tag. The long press should no longer put it into text copy mode. See if that fixes its behavior.

What I would expect, assuming the Kobo touch behaves as I would expect it to, is that it will behave similarly to iOS, which means the onmousedown should fail with a time of zero (iOS usually sends onmousedown and onmouseup when you stop touching the button), but the ontouchsstart should pass. At least that's what I'm hoping will happen.

Regarding the latency test, I suspect that isn't going to tell me what I need because of the slow refresh rate of the e-ink screen. Maybe I should have done whole seconds instead of tenths. Fixed.

The bigger question I was trying to answer, however, can probably be answered by anyone who actually uses the device, and that is this: how long does it take between when you tap a link and when something starts happening?

On the Kindle Touch (which I'm returning), it had almost a two second lag between a button press and when anything started happening, which for my purposes is about two seconds too long. On my iPhone, or my laptop, it's essentially instant, which is what I'd expect from a browser.

[KevinShort]

Tried it on my Kobo Touch, the results are as follows:

onclick: pass

onmousedown: fail (time = 0.0)

ontouchstart: fail

latency: 0.5 seconds

[dgatwood]

Bummer. It sounds like the Android tablets are the only ones with viable browsers. *sigh*

[notzed]

Well, there's a good reason custom applications are the primary software delivery mechanism for phones and closed-ecosystem tables. Web pages are slow, ugly, and inefficient: it's just that we're all now use to them, and desktop computers are so blazingly fast most of us don't notice how bad they are.

The kobo touch hardware is more than capable of running local software quite well - and for the most part the bundled software is not a terribly good example of what it is capable of (it is the one dropping input events or taking an age to hear them for example). The e-ink display is still something of a challenge, but it is what it is.

[dgatwood]

I agree that the ability to load apps is desirable. For that reason, given a choice, I would categorically reject any tablet that doesn't come with either an app marketplace or the ability to side-load apps. Unfortunately, right now, that would eliminate *every* e-ink-based tablet on the market, as far as I can tell, short of rooting the Sony or Nook Touch readers.

Maybe I should just wait a few months for actual Mirasol-based Android tablets to appear.

That said, I disagree with your assertion that web apps are slow, clumsy, and inefficient. Apparently you haven't seen the ports of Doom and Quake that ran/run entirely in JavaScript. (Okay, I'll grant you inefficient, but slow and clumsy, they are not.) The development environment for browser-based apps is still in its infancy compared with desktop apps, but that doesn't mean that they will always be lame imitations of their native app cousins....

The main reason that custom apps are the primary delivery mechanism for tablets and phones is that you can trivially sell a custom app on official app stores, whereas it's relatively hard to sell access to a web page.... It has nothing to do with the browser not being up to the task by any stretch of the imagination.

[notzed]

Well I've been writing stuff for the kobo touch without too much hassle. It's running a fairly complete linux and it uses standard device interfaces such as /dev/fb0, enabling telnet is trivial so it's easy as to investigate and code for. The kernel source is readily available and the drivers even documented by mavell. The machine is reasonably snappy (but slow disk), and the touch input device quite fast and fairly accurate.

But unless you're writing a turn-key application or just for fun, android or some other open platform would be worth waiting for. Although you could probably get a version of android to run on the kobo touch, the e-ink would probably force some changes - all those annoying animations and interactivity responses become much more than just annoying on e-ink.

There are many reason 'apps' have become so popular, and performance is definitely one of them.

Doom on a browser? Err yeah, so it should do. Based on http://www.7-cpu.com/ a modern cpu is about 1500-2500x faster than one of the age it was released. Even the kobo touch cpu is 25x faster than a 486-dx2-66, and iirc doom ran quite well on one of those.

It might be fun and cool, but hardly impressive when taken in perspective. It will be some time yet before a browser can run uncharted 3 ...