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

@Jidanni: Please do read instructions. All of them. Thanks.

Looks like I need to go to https://commons.m.wikimedia.org/wiki/Main_Page and select links in the sidebar.
I can confirm with Firefox 121 on an Android mobile.

This does not seem to be an issue with code on Commons thus removing project tag of the Commons community (please set project tags if possible).

The problem does not happen in the mobile frontend on desktop.

Works for me.
More information please.

• Does this issue happen in safe mode?
• Does this happen incognito?
• what devices? (My firefox chrome looks different from the screenshot)

The problem does not happen in the mobile frontend on desktop.

Could you expand on what you mean by this comment? Do you mean Minerva on desktop?

I go to https://commons.m.wikimedia.org/?safemode=1 in an incognito window of Firefox 121 on an Android 10 device, select the hamburger menu, click "Log in" or "Settings", the side bar closes but nothing happens: Browsers stays on the frontpage.

The problem does not happen in the mobile frontend on desktop.

Could you expand on what you mean by this comment? Do you mean Minerva on desktop?

Yes, Minerva on desktop while still accessing the https://commons.m.wikimedia.org/ domain.

Well it's not a gadget, because it even fails in an incognito window.

Maybe your friend has an Android 13 device you can test on.

Maybe your friend has an Android 13 device you can test on.

We have been unable to replicate on a variety of devices.

Well it's not a gadget, because it even fails in an incognito window.

Thanks for confirming. Would it be possible to upload a screen recording of the issue? That might help us identify potential problems.

Well, I just tested it on an Android 8 cellphone, and your page works perfectly.

But on an Android 13 cellphone, I'm sorry to tell you, no matter if it's Chrome Beta, Samsung Internet browser, Kiwi browser, etc. etc. no go: for instance just touching that login button just closes the side panel. That's the awful truth.

And I tried even the smallest font size in Android settings and it doesn't help. So the big difference is you need to test it on Android 13. Like my Samsung A13 5G.

I'm sorry I can't send any movies because of bandwith issues.

In T354315#9439675, @Jdlrobson wrote:

If it just commons it could be a gadget installed that is interfering with their functionality.

It is not just Commons. I have the same problem on metawiki and frwiki (incognito window, not logged in, in both Firefox on Chromium on Android 10).

Please follow https://www.mediawiki.org/wiki/How_to_report_a_bug to help us diagnose this better by ruling out common problems.

Which specific information is missing? Could you be more specific please? (I don't plan to install third-party Replay.io on my phone, sorry.)

I can reproduce this on enwiki with:

• Android 14, animations disabled (under Android Settings -> Accessibility -> Visual Enhancements -> Remove animations), Firefox Nightly 123
• Android 14, animations disabled, Chrome 120
• Desktop Linux, Firefox 120, animations disabled (add "ui.prefersReducedMotion" as a numeric preference, and set it to "1")

I cannot reproduce this with:

• Android 14, animations enabled, Firefox Nightly 123
• Android 14, animations enabled, Chrome 120
• Desktop Linux, Firefox 120, animations enabled
• Desktop Linux, Firefox 120, animations disabled and JavaScript disabled

Note that at this VPT thread, another user is having the same problem, but with animations enabled.

It is not just Commons. I have the same problem on metawiki and frwiki (incognito window, not logged in, in both Firefox on Chromium on Android 10).

Are there any sites where the error does not occur?
Knowing that would be helpful to determine if the code might be site specific which would narrow this down to app/browser extension/sampling. For example does it occur on French Wikisource?

What's curious about this bug is some people can replicate it, some can't on the same device. This makes me think it either relates to:

1. Something that makes use of sampling e.g. instrumentation.
2. Some kind of browser/app setting (the animations disabled is a great example of something that could implicate things- but unfortunately that didn't help me replicate it myself (on OSX not Linux)
3. An app/browser extension that's installed that is interfering with links in Wikipedia articles/network requests.
4. Some kind of race condition.

Which specific information is missing?

A screencast would be most helpful at this point and give some clues about what might be happening. Most Android devices have a "screen recorder" mode which might help there.
Even better, if someone who is experiencing this bug, could connect their device with the issue to Chrome using https://developer.chrome.com/docs/devtools/remote-debugging and let me know if there are any errors in the console or network tab.

In absence of that @suffusion_of_yellow 's example is a really good one that's helpful (although sadly I was unable to replicate it myself with any of the cases) - it would be useful to get a few more like that that include browser version, OS version, portrait/landscape and type of device (e.g. Android 13 Samsung A13 5G Chrome 120 landscape mode as a good example). In addition to that, please check if you have any accessibility settings enabled that are different from the factory default in your browser or operating system? e.g. font size, animations disabled, touch and hold delay, tap duration, slow keys, bounce keys. If you are open to it, try resetting to factory default and see if the problem goes away.

Thanks in advance.

Indeed, it seems the critical item is the animation setting.
But we cannot blame the user.
Let's see what that setting looks like:

I can reproduce it in all of the browsers I have available in Linux (both Firefox (version 121) and Chrome-based (several different browsers spanning a wide range of Chrome versions) by going to https://commons.m.wikimedia.org/ in a private window and trying to click the login link. I always have animations turned off.

TDLR: Still not sure what has led to this bug but think I know what the error state is and have a few potential ideas on how we might fix it. More information (particularly remote debugging from someone who can replicate the issue) would be helpful to fix this, as I'm not confident in my diagnosis.

Longer version:
This is definitely one of the stranger bugs I have ever had to debug. I am unable to replicate this on any device but I think I know what the error state looks like.

The error state seems to arise when the transition CSS rule is disabled by removing the minerva-animations-ready class.
The bug goes away with the following CSS:

#mw-mf-page-left { transition:opacity 250ms ease-in-out,visibility 250ms ease-in-out,transform 250ms ease-in-out; }

The question is why would a transition impact the ability for a link to work?

The CSS class is being added unconditionally added here: https://gerrit.wikimedia.org/g/mediawiki/skins/MinervaNeue/+/99f457d3a8f205f509da3a04162df23bcb4d7e4d/resources/skins.minerva.scripts/initMobile.js#384

It should only ever not add if either:

1. JS is not running.
2. A JS error is occurring somewhere in page load that stops execution.
3. A global reset exists that looks like this:

#mw-mf-page-left { transition: none !important; }

I am not sure which one of the above is true.

There have been no changes to the codebase in a few months. In fact when I looked at the last month of MediaWiki versions the bug is present in all versions. For that reason this feels like it might be a new upstream Chromium bug.

In short term, I'd recommend removing minerva-animations-ready class (I believe this is mostly to workaround a previous Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=332189 which may be fixed now). If that's not an option.

If someone is able to replicate this, it would be extremely helpful to know if this relates to any errors in the JavaScript console using https://developer.chrome.com/docs/devtools/remote-debugging. That will likely lead to diagnosing this quicker and finding a better short term fix.

...ms...

(All I can say is having milliseconds in the code is asking for trouble.
In fact it's things like that that cause the Upload form to fail for people with less high speed networks.
I would only mention times with long times like 60 seconds for timeouts.)

So stepped through this with the debugger and I think I see what going on here.

1. Focusing on the "settings" link triggers an event handler created by bindDismissOnFocusLoss() which calls dismissIfExternalTarget()
2. This checks if event.target is outside target. But target is not the menu, it's only the first three items ('.p-navigation')
3. So even though we clicked inside the menu, the menu is dismissed

The is much more obvious if you use the keyboard to navigate. Open the menu, then tab - tab - tab - tab, and it's gone!

Now what is supposed to happen if you hide an element from inside a focusin handler? Is the click that triggered the focus change still registered? I have no idea if that's even specified in any standard, but I wouldn't be surprised if it's browser-dependent.

The animation only serves to slow done the hiding of the element, so the click has time to register.

Change 990144 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Update checkboxHack target node

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

So after a browser update I'm finally able to replicate this on production but not locally. Seems the the animation class/ transition has nothing to do with it so I was barking up the wrong tree.

I can confirm removing the focusin event listener addresses the issue in production. (Thanks @suffusion_of_yellow for getting me back on path !)

So in conclusion, I think there has been a change in browser behaviour impacting existing code (for example maybe clicking a checkbox now cancels any network requests?).
https://gerrit.wikimedia.org/g/mediawiki/core/+/cab3f6e305ec204e88b7ce3c863eb5ee3c0d7728/resources/src/mediawiki.page.ready/checkboxHack.js#210

The above patch seems the easiest way to address this.

[mediawiki/skins/MinervaNeue@master] Update checkboxHack target node

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

Is that going to break the user menu (.p-personal)?

Change 990144 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Update checkboxHack target node

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

Change 991050 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@wmf/1.42.0-wmf.13] Update checkboxHack target node

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

In T354315#9460987, @suffusion_of_yellow wrote:

[mediawiki/skins/MinervaNeue@master] Update checkboxHack target node

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

Is that going to break the user menu (.p-personal)?

It shouldn't do but you are welcome to test the fix on https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=T354315 (and any feedback would be helpful!)

Change 991339 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@wmf/1.42.0-wmf.14] Update checkboxHack target node

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

Change 991339 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@wmf/1.42.0-wmf.14] Update checkboxHack target node

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

Change 991050 abandoned by Jdlrobson:

[mediawiki/skins/MinervaNeue@wmf/1.42.0-wmf.13] Update checkboxHack target node

Reason:

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