Page MenuHomePhabricator

taps on page A end up being processed on page B
Closed, InvalidPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Google Martin Luther King
  • Visit the Wikipedia article offered
  • Then in the "文A" menu, pick the 中文 version.

What happens?:
Well we indeed visit all the pages we intended,
but in the process we also unintentionally also visited Jim Crow Laws, and Special Pages, and had to use the browser's back button, twice.

What should have happened instead?:

Our taps should have been interpreted on the hyperlinks we thought we were tapping on. Instead they ended up being interpreted on the same screen position, but on different pages, that were apparently in the process of loading, due to Wikipedia being slower than other websites.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Chrome.

Screenshot_20250613_204350_Chrome Beta.jpg (525×287 px, 47 KB)
(reusing screenshot.)

Event Timeline

Aklapper changed the task status from Open to Stalled.Jul 2 2025, 12:34 PM

Your browser history screenshot shows that your browser went from www.google.com to the page "Jim Crow laws" on English Wikipedia.
How is that a software issue in software on Wikipedia servers?

but in the process we also unintentionally also visited Jim Crow Laws, and Special Pages, and had to use the browser's back button, twice.

Neither can I reproduce nor can I follow. Please always provide complete steps to reproduce, as a list of steps.

The problem is caused by the user clicking/tapping several times
in the same spot.

Just like on a Linux computer terminal, if we hit

CTRL+S t t t t t CTRL+q

We don't see any of our t's, until we hit CTRL+q, and then we see all of them.

So on a unresponsive web page the user might click several times in the
same spot.

Then later when the page becomes responsive again, each click would be
processed one by one. So instead of just landing on link A on page 1,
they might also end up on link B of page 2 and link C of page 3 etc.

Worst would be an "Agree?" link in the same position on a several page
questionnaire.

The user might end up agreeing to the whole document due to having
clicked several times on a temporarily unresponsive page 1.

As for today's problem, it is hard to reproduce, as we aren't sure of
the exact browser size and how far the user (me) had scrolled down before
clicking.

Also the site is rather snappy today, no delays.

OK hard to reproduce. So I'll close it.

The problem is caused by the user clicking/tapping several times in the same spot.

We are neither the Google website nor are we your web browser. So what do you expect Wikimedia software to do here, at this stage?