Last modified: 2014-10-07 05:54:35 UTC
Search for something on enwiki in desktop Chrome, click one of the results. Search overlay closes but I stay on the same page. When I repeat the same steps second time, it works. Can't reproduce on Android Chrome, so not sure how serious it is, but it feels alarming.
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/v11pdWWl
Yeh I think Arthur raised this issue a while ago and I occasionally see it. I can't work out why though :-/
It seems to be related to tap area. I've been able to produce it on my Chrome mobile and occasionally desktop chrome but never reliably.
Change 135820 had a related patch set uploaded by Jdlrobson: Avoid bugs in Chrome with clicking links in search overlay https://gerrit.wikimedia.org/r/135820
Change 135820 merged by jenkins-bot: Avoid bugs in Chrome with clicking links in search overlay https://gerrit.wikimedia.org/r/135820
This is still happening for me now and then. I also saw other people hitting it when testing on tablets.
This also regularly happens for me. The bug is present in both the desktop and Android versions of Chrome.
I have not been able to reproduce this bug on desktop or mobile. Tried Chrome and Firefox on desktop and Mobile Safari on iOS.
I've noticed it in Chrome on desktop sometimes, but not very often. Maybe it's only because of the input field isn't big as the header (see attachement for what i mean), so maybe sometimes i click besides :)
Created attachment 15671 [details] Height of search input
Still not able to reproduce. Could someone provide more details about how they are producing this bug? What page are you starting your search from on en.wiki? What are you searching for? What are you clicking on? Any further details would be appreciated.
I've tried reproing this on a phone and tablet (iPhone 4 and iPad), in alpha, beta, and stable, in production as well as beta labs, and I don't see it. However, on desktop (Chrome), both in prod and on beta labs, I *do* see it. Here's what's up: 1) Visit en.m.wikipedia.org in your desktop browser 2) Click into search and type "San Francisco" 3) Click on the word "San Francisco" -- you'll be taken to the page as expected But! 4) Click into search again and type another term, say "Barack Obama" 5) Click on the whitespace around the words Barack Obama but not on the words themselves -- nothing happens.
Hmm, on desktop chrome i can reproduce this in beta and stable, not in alpha. And there aren't any infos/errors in console :/
Still can't reproduce it :(
Change 142743 had a related patch set uploaded by JGonera: Fix double tap/click bug in search overlay https://gerrit.wikimedia.org/r/142743
Change 142743 merged by jenkins-bot: Fix double tap/click bug in search overlay https://gerrit.wikimedia.org/r/142743
1. Visit en.m.wikipedia.org in Chrome on Android or Windows. I recommend doing it in Incognito Mode to guarantee a "fresh" browser experience, but the bug is present either way. 2. Click or tap in the search area and enter "The Hound" 3. Click/tap on "The Hound of the Baskervilles" Expected: Browser navigates to the "The Hound of the Baskervilles" page. What actually happens: Nothing. On desktop Chrome, if I then repeat steps 2 and 3, the correct page loads. On Android Chrome, it does not--although this technique seems to work for certain other pages on Android. These steps have been verified just now in Chrome 35.0.1916.141 running on Android 4.4.4 KitKat on a Google Nexus 7 tablet, and in Chrome 35.0.1916.153 running on Windows 8.1.
> What actually happens: Nothing. Reproduced on Chrome mobile (not on HTC Stpck browser). But if i'm right, the merged PS of JGonera isn't deployed on Wikipedia Wikis, so we wait until the patchset is deployed and test, ok? :)
Change 165029 had a related patch set uploaded by Robmoen: Longer timeout for history update on search click https://gerrit.wikimedia.org/r/165029
Change 165029 merged by jenkins-bot: Wait for back history before going to search page https://gerrit.wikimedia.org/r/165029
