I can't reproduce this :( Tested on https://en.wikipedia.org/wiki/Heart#Additional_images. What page are you testing? Can you record it?

Sure! Also, I just found out that this is happening on Firefox only.

This is a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1495482

Here's a minimal test case for the issue:

<input type="number" />
<script>
document.getElementsByTagName('input')[0].focus();
alert( document.getSelection().anchorNode.tagName );
</script>

To work around this, I think we would have to wrap every access to properties of Selection#anchorNode and #focusNode in a try…catch. At a glance that's ~50 places in the codebase. Certainly possible, but that's a lot of work (and a lot of ugly code to maintain in the future), so I'd like to see if anyone has any better ideas.

Alternatively, we could stop using <input type="number" /> in our code (or NumberInputWidget), and use type="text" instead (TextInputWidget). But we would probably have to add manual validation to each of them if we do that, and the interface is worse, especially on mobile (where number inputs have a specialized keyboard).

The Firefox bug has been reported 2 months ago with no response yet.

This appears to be the problem reported here: https://fr.wikipedia.org/wiki/Wikipédia:Questions_techniques/semaine_46_2018#Comment_contrer_un_bug_de_l%27éditeur_visuel_%28galerie_d%27images%29_et_ne_pas_perdre_une_modification

To work around this, I think we would have to wrap every access to properties of Selection#anchorNode and #focusNode in a try…catch. At a glance that's ~50 places in the codebase.

We usually access the native Selection object via ve.ce.Surface.nativeSelection, so perhaps we could somehow modify the accessor function for those properties.

Looks like Proxy breaks methods, but we can use defineProperty and carefully extract the original value. A truly horrendous workaround.

We can also try to avoid any of the CE surface code running when the focus is in a dialog, because it isn't necessary.

Let's say we introduce a getter/wrapper for .anchorNode and .focusNode, either using Proxy, using defineProperty, or just a new method and search-and-replace. But what should this getter actually return when the real anchorNode/focusNode is broken? I have no idea if we might break any assumptions in our other code if we return the "wrong" element, and we can't return the right one. That's why I thought we would have to do it separately for every place where it's used. For the most part, we only do things with anchorNode/focusNode inside our contenteditable node, but I'm not sure if this is always true.

document.activeElement.parentNode

Change 474533 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Workaround native selection bug for number inputs in Firefox

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

Change 474533 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Workaround native selection bug for number inputs in Firefox

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

Change 475825 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (6a2233f68)

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

Change 475825 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (6a2233f68)

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