bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/gfTmzanP

Works fine for me. Can you provide additional details such as what browser you are using and what page you are searching from?

firefox 30 on android 4.4.4, searched on main page, but happened on others too.

Hmm, tried to reproduce in desktop Firefox 30, but no luck. I'll see if I can reproduce on Android when I'm at the office tomorrow.

jgonera wrote:

I tried on desktop Chrome and Firefox with Hebrew (lyx) keyboard on Linux, can't reproduce. I'll try to figure out how to install Hebrew keyboard on my Android phone...

jgonera wrote:

I reproduces it. Actually, only tapping on the search input (without typing) already takes me to the previous page. It sometimes happens on Chrome too. I can't reproduce on latest master on my local dev env. I suspect it might be this weird banner that is displayed on the top of the page that is causing this.

Reproduced on en wikipedia, too. There is Wiki loves earth as Sitenotice (not seen, bc dismissed for my wiki account). If i click (in Chrome for Android, HTC One) the search bar, i will be redirected to the previous page.

jgonera wrote:

Yeah, saw it on enwiki the other day too...

I have confirmed with certainty that this bug is dependent on CentralNotice banners being active.

mwalker wrote:

Any banner? Or just the WikiLovesEarth banner?

Seems to be any banner. Need to investigate further though.

The bug does not happen for me after the banner is dismissed, however.

So far reproduced in Chrome for Android and Mobile Safari. Haven't been able to reproduce on any desktop browser.

Actually, it's any banner that is 40 pixels or taller.

OK, I think I know what's going on. When you click on the search input, the search overlay renders at the top of the page. When there isn't a CentralNotice banner, it renders under the user's finger. When there is a CentralNotice banner (that's tall enough), it renders above the user's finger. The SearchOverlay.js code includes a bit of logic (lines 70-73) that executes window.history.back() whenever the user clicks outside of the overlay. This normally just closes the overlay due to the M.router functionality. In this case, the user clicking on the search input is getting read as a click outside the search overlay (assuming the user's finger remains on the screen for more than a split-second). Because either the URL hasn't been rewritten yet or the M.router code hasn't finished executing, it actually sends the user to the previous page when it executes window.history.back() (instead of just closing the overlay).

I asked Moiz about moving the banner under the header, but he says it makes more sense to leave it at the top. Other possible solutions:

• Use a touchend event to trigger the launch of the search overlay.
• Make sure the window.history.back() doesn't execute until the URL has been rewritten and the M.router registration has finished executing.
• Make sure the search overlay is always positioned exactly above the search header (also would need to reposition on window resize).

There are probably some other options as well.

Change 146684 had a related patch set uploaded by Kaldari:
Making sure that clicking on search doesn't trigger history.back()

https://gerrit.wikimedia.org/r/146684

Change 146684 merged by jenkins-bot:
Making sure that clicking on search doesn't trigger history.back()

https://gerrit.wikimedia.org/r/146684

Change 150368 had a related patch set uploaded by Kaldari:
Making sure that clicking on search doesn't trigger history.back()

https://gerrit.wikimedia.org/r/150368

Change 150368 merged by jenkins-bot:
Making sure that clicking on search doesn't trigger history.back()

https://gerrit.wikimedia.org/r/150368

Backport to 1.24wmf14 merged; closing again.