637175 - Clickable elements that aren't links or buttons (e.g. Google Reader touch interface elements) do not highlight on tap

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mikko Ohtamaa]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: beta 5

Google Reader touch interface "Mark as reader" link is "hard to hit". You do not know whether touching it has succeeded or not.

It does not happen always. Most of the time the link responds normally, but it is definitely possible to reproduce bug with normal usage.


Reproducible: Always

Steps to Reproduce:
1. Open Google Reader (touch)
2. Scroll to bottom
3. Press "Mark as reader"
Actual Results:  
In 10% cases the press takes 5-10 seconds to produce any visual clue

Expected Results:  
The press gives instant feedback (like with other browsers)

I suspect this has something to do with the fact that the link is a Javascript based.

UI must do IPC with the engine and wind up Javascript to process the link press? Somewhere along the line is IO which kills the performance?

I'll try to come up with an usage pattern which allows to repeat this bug with high certainty.

This bug also plagued Maemo native Nokia browser.

Tested devices: N900, Samsumg Galaxy S on A2.2.

Comment 1

[Matt Brubeck (:mbrubeck)]

All of the links/buttons in http://google.com/reader/i fail to highlight when tapped in Fennec.  The same is true of some other sites, like http://touch.facebook.com .

I suspect these sites use event delegation in a way that Fennec doesn't recognize that the individual elements are "touchable" (i.e. are links or have click event listeners).

Comment 2

[Matt Brubeck (:mbrubeck)]

The touchable elements on http://google.com/reader/i are <div>s, so they do not match any of the :active selectors here:
http://mxr.mozilla.org/mobile-browser/source/chrome/content/content.css#331

Just adding "div:active" is not workable, because this will include all containing divs (not just the targeted div).  Maybe we can set some other attribute on the target which we can use in a selector?

[Google could fix this by adding the ARIA role=button attribute to their buttons, but we can't expect all sites to do this; we need to make this work without content changes.]

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: patch

Add a secret class to clickable elements.  The advantage of this is simplicity.  The disadvantage is that it is potentially visible to web content.

Also fixes a problem with the "buttons" on the Google page: Since they have a background-image, our background-color does not show up.  With this patch, we properly override the entire background.

Comment 4

[Matt Brubeck (:mbrubeck)]

Nominating for Fennec 4.0.  This is a fairly simple fix for a high-visibility polish issue that affects mobile versions of Google Reader, Google Groups, Facebook, and other sites.

Comment 5

[Wesley Johnston (:wesj)]

Comment on attachment 517006 [details] [diff] [review]
patch

I know it was my idea, but I'm pretty leery of this. We don't really need more overhead added to click events. And this is available to web content, which sets a strange precedent I don't want to deal with.

I think maybe we are better waiting until Fennec.Next and writing a better solution (perhaps adding a better pseudoclass for tap highlighting, or at least for clickable elements?)

Comment 6

[Matt Brubeck (:mbrubeck)]

Comment on attachment 517006 [details] [diff] [review]
patch

Yeah, I agree.  I'll go back to the drawing board.

Comment 7

[Mikko Ohtamaa]

I am not sure whether my bug report was correctly understood.

Google Reader itself gives feedback for the touch event for this particular <div>. It changes the text "Mark these items as read" to "Marking these items as read". 

However, sometimes there is an unnecessary delay or ignore that the command was correctly giving. Either

1. The delay to change the text is so long (Javascript processing) that the user gets frustrated 

2. You missed the target (because it is not <a> special touch boundaries are not active?)

Because you don't know whether it is 1 or 2 you keep pressing the link and nothing happens...

The fact that buttons fail to highlight is an issue too, but that was not the issue I was reporting :) Should I split this bug report?

Comment 8

[Matt Brubeck (:mbrubeck)]

Yes, it sounds like this should be two bug reports.  Sorry for the misunderstanding.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Matt, what's the plan here?

Comment 10

[Mikko Ohtamaa]

Just to note: now testing Galaxy S and FF6 beta - the responsiveness has gotten much better, though I believe the expanded hit area of the click event might be  still missing.

Comment 11

[Adrian Tamas (:AdrianT)]

The issue is no longer reproducible on Native Nightly 15.0a1 2012-05-27. Mark as read works on the first tap and feeds are marked read the moment the user taps the link.

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to adrian tamas from comment #11)
> The issue is no longer reproducible on Native Nightly 15.0a1 2012-05-27.
> Mark as read works on the first tap and feeds are marked read the moment the
> user taps the link.

Google reader also works for me on Firefox for Android Beta 14. I'm resolving as fixed.