Nightly 27.0a1 2013-09-23 Asus Transformer TF101 Steps to reproduce: 1) Open the Bookmark tab 2) Tap on the first bookmark 3) Tap on the 2nd bookmark Expected results: The correct bookmark is opened every time Actual results: At step 2 nothing happens At step 3 the 1st bookmark is opened When opening a bookmark the previous bookmark in the list is opened

Long tap seems to work correctly

This has to do with the header views. But already have checks for those. :(

Sriram, could you have a look at this bug?

Took this bug as it's kinda or urgent (it blocks 2 other tracking bugs for Fx26). It seems the 'position' argument for onItemClick() already accounts for the header views for us. Reading list has the same top divider and doesn't account for header view in its onItemClick handler either. To be honest, this is a bit surprising given that we do have to account for header views in the TopSitesPage's onItemClick handler.

Comment on attachment 813044 [details] [diff] [review] No need to account for header views in Bookmarks page Review of attachment 813044 [details] [diff] [review]: ----------------------------------------------------------------- This is strange. If it works, I'm fine with this patch.

(In reply to Sriram Ramasubramanian [:sriram] from comment #6) > Comment on attachment 813044 [details] [diff] [review] > No need to account for header views in Bookmarks page > > Review of attachment 813044 [details] [diff] [review]: > ----------------------------------------------------------------- > > This is strange. If it works, I'm fine with this patch. Yeah, it works fine.

Comment on attachment 813044 [details] [diff] [review] No need to account for header views in Bookmarks page Any ideas for how to test for this kind of issue?

(In reply to Mark Finkle (:mfinkle) from comment #8) > Comment on attachment 813044 [details] [diff] [review] > No need to account for header views in Bookmarks page > > Any ideas for how to test for this kind of issue? This is covered in testBookmark and testBookmarksTab Robocop tests. Unfortunately I didn't manage to re-write and re-enable the tests yet with all the changes to about:home. I'll test the patch for testBookmark tomorrow and will start the re-write of the patch in testBookmarksTab to account for the changes done in the new-new-about-home test

Lucas, this is needed on Aurora

Comment on attachment 813044 [details] [diff] [review] No need to account for header views in Bookmarks page [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 862793 (new about:home) User impact if declined: Wrong URL is loaded when tapping on bookmarks (on tablets) Testing completed (on m-c, etc.): In m-c for a week or so, no issues. Risk to taking this patch (and alternatives if risky): Low risk, just removing some unnecessary code that was causing problem. String or IDL/UUID changes made by this patch: n/a

This is the cause of the permaorange rc1 on Android 4.0 on Aurora, so that should clear up once this gets approval and gets landed.

Verified as fixed on Firefox 26 Beta 6, on Samsung Galaxy Tab(Android 4.0.4)