Thu, Jun 30
Wed, Jun 29
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.
Aug 12 2021
At this point, I cannot reproduce the bug as reported, neither on Firefox nor on Safari, neither in Desktop nor in Mobile view.
Jul 31 2021
May 10 2021
May 6 2021
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.
May 5 2021
Mar 20 2021
Sep 8 2020
Jun 23 2020
May 5 2020
Dec 24 2019
Oct 20 2019
Oct 11 2019
The issue is fixed on live Wikipedia, so I'm closing. Thanks everyone!
Sep 28 2019
Apr 3 2019
Mar 17 2019
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.
Mar 16 2019
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.
Mar 15 2019
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.
Dec 22 2018
Dec 9 2018
May 8 2018
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
May 6 2018
Jan 28 2018
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.
Nov 10 2017
Oct 18 2017
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.
Oct 6 2017
Oct 2 2017
Aug 9 2017
Apr 4 2017
May 4 2016
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
Feb 23 2016
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.
Feb 17 2016
Feb 14 2016
In fact, Mediawiki's rendered wikitext does break lines just before footnotes, so this bug report is entirely invalid.
Feb 12 2016
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.
Feb 11 2016
Jan 19 2016
Jan 12 2016
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.
Dec 28 2015
Dec 22 2015
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.
Sep 29 2015
Sep 12 2015
It is now 4:18 PM CDT and I can reach all Mediawiki sites again.
May 23 2015
May 12 2015
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.
May 1 2015
Apr 24 2015
Apr 16 2015
I cannot reproduce the issue anymore with the current version of VE installed on Wikipedia [0.1.0 (685e7ff) 12:17, 8 April 2015].
Apr 10 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.