I'm now on Android 10 using Firefox 129.0 and a larger phone. I see the following behavior on all articles I tried:

Yes, it seems fixed now. I tested on Windows/Firefox and Windows/Chrome.

If you compare https://maps.wikimedia.org/#10/49.0887/33.3064 and https://www.openstreetmap.org/#map=10/49.0887/33.3064
you will see that the former lacks the large blue body of water in the upper left; this is the Kremenchuk Reservoir https://www.openstreetmap.org/relation/2289192.

At this point, I cannot reproduce the bug as reported, neither on Firefox nor on Safari, neither in Desktop nor in Mobile view.

Investigating further, I believe the bug happens 100% of the time if you cut-and-paste a reference that exists only once in the article, and 0% of the time if you cut-and-paste a reference that is used several times in the article.

Click on

I can reproduce the problem on https://en.wikipedia.org/w/index.php?title=Woodgate,_Queensland&oldid=922128021 using Chrome 77.0.3865.120/Windows 7. When trying to cut the second sentence of the intro section, it doesn't work and the javascript console reports the error

The issue is fixed on live Wikipedia, so I'm closing. Thanks everyone!

I see. I think it's a mistake to have T217259 closed as a duplicate of this bug; they are separate issues. I have reopened it.

This is not the same issue as T211490: that bug is about the wikitext inside of the editing text box not being scrollable under certain circumstances; this one is about the buttons on top of the editing text box sometimes scrolling out of view.

Hello @RhinosF1, I don't fully understand your reply. My question is this: can you still reproduce this bug (the wiki text inside the editing area cannot be scrolled further up just after an edit session has been started and the virtual keyboard has appeared) on your iphone?

@RhinosF1 - It's not quite clear to me what you are seeing with persistence and zooming. Is it the exact bug described here, i.e.: the wiki text inside the editing area cannot be scrolled further up just after you've started an edit session and the virtual keyboard has appeared?

The issue is fixed, I'm closing.

This is fixed now, thank you! I'm closing as Resolved.

I'm currently on Android 8.1 running Chrome beta 73.0.3683.75, still on the small Galaxy S2, and the bug as described above is not present anymore. I'm closing as resolved.

Thanks @Jdlrobson for providing context. Browsing through those tasks, I found a beautiful mockup by @Nirzar which I fully endorse: https://phab.wmfusercontent.org/file/data/7rjsvgpnschrjom3seee/PHID-FILE-fmamkpptm7k2uqshnpvt/footer-3.png

I could not repeat the described aberrant behavior on Chromium 63/Linux.

With the new style of link editing, the problem I described above has gone away. So this can task can be closed.

The browser window doesn't have to be that small for the effect to appear. On my 14' laptop, it already happens if the windows is about 75% of the width and 75% of the height of the screen.

I just reinstalled the browser and all Wikimedia sites work fine now. I am sorry for having wasted everybody's time.

None of maps.wikimedia.org, stats.wikimedia.org, phabricator.wikimedia.org, meta.wikimedia.org, commons.wikimedia.org, wikitech.wikimedia.org and gerrit.wikimedia.org work for me.

Yes, I mean only *.wikimedia.org sites.

My information: IE Version 11.0.9600.18282CO, Windows 7 Enterprise 64bit Service Pack 1, build 7601, 7601.23391.amd64fre.win7sp1_ldr.160316-0600

I just noticed that everything works fine if I disable the Navigation popups gadget in my user preferences. I'll edit the problem description and task title accordingly.

In fact, Mediawiki's rendered wikitext does break lines just before footnotes, so this bug report is entirely invalid.

This was closed as a duplicate of T96487. However, while T96487 has been resolved, the issue described here remains. So I am re-opening.

In Microsoft Word, both character-level styling and paragraph-level formatting are only applied to the one line that was selected either with Cursor-at-beginning-plus-Shift-Cursor-down or with a triple-click. In three of these four scenarios, VE behaves as Word.

The use of colons to indent lines will be familiar to most users since it is widely used on discussion pages. Users will prefer it over <blockquote> since it's shorter and a line can be indented to any desired level.

I spoke too soon: the French Wikipedia also often uses

I have seen this convention in place in the English, German and French Wikipedias. I have not checked any others.

It is now 4:18 PM CDT and I can reach all Mediawiki sites again.

The bug occurs whenever the offending line containing mismatched bold/italic is preceded by an image, a template, or any line of wikitext. It doesn't occur if the offending line is the first line of the article.

I cannot reproduce the issue anymore with the current version of VE installed on Wikipedia [0.1.0 (685e7ff) 12:17, 8 April 2015].

If you close the first link inspector window, scroll down another screenful, and create a new link, the spurious scrolling will happen again. The effect is bigger if your new link is near the top of the edit window.

Both my issues on en.wiki and on mediawiki.org are resolved (Chrome 39).