I figured out why this happens:
Thu, Dec 5
It applies to the "user education popups" in the toolbar, indicated by the blue pulsating dots.
I just saw that the patch for T219380: [regression] API-only preferences can't be set was recently backported to MW 1.33 and was reminded of your problem. GlobalPreferences is in fact installed on your test wiki, and I see also that you already upgraded to include that backport. Is this resolved now?
Wed, Dec 4
We should probably make option 4 work (action=edit&veaction=editsource). Task T190765 is a similar problem.
After T209163 was resolved, the main problem here disappeared (simply refreshing the page doesn't land you on an URL that triggers this issue), but if you manually construct that URL (or click on a link elsewhere that points to it), NWE still doesn't load.
Tue, Dec 3
The page was edited since this task was filed and the table is no longer separately scrollable. The bu can be reproduced in the older revisions, e.g. https://en.wikipedia.org/w/index.php?title=2019_Albania_earthquake&oldid=928340639
(We discussed by email and those two are definitely not used.)
I think it's all done, in fact, but we forgot to move it.
First rough idea of how it might look like:
Mon, Dec 2
I can reproduce this. The list of categories is a <ul>/<li> list, but styled using CSS to display as plain text. Apparently when you copy-paste it, you end up with <li> nodes without the parent <ul> node, which breaks assumptions in our Converter code and blows up.
Hmm at this point it might be easier to edit the page to avoid this.
Sun, Dec 1
I can reproduce this, on testwiki only. It works correctly e.g. on enwiki.
This seems to affect all pages, e.g. also https://en.m.wikipedia.org/wiki/Ryan_Murphy_(writer).
Fri, Nov 29
Thu, Nov 28
I can reproduce this by viewing the old revision (https://en.wikipedia.org/w/index.php?title=Template:Infobox_earthquake&action=edit&oldid=923488651).
It seems that the screenshot wasn't actually attached, so I can't be sure, but it seems like this problem doesn't occur any more. I just tried VE in IE11 and I did not see any overflow in the toolbar dropdowns.
Reproduction steps (without messing with the code, and without the server being broken somehow, which is the usual cause of failed loading):
- Open a page in read mode
- Open the editor
- Close the editor without reloading the page (e.g. press Escape key on the keyboard)
- In your browser's developer tools, enable "Offline" mode (or turn off your Wi-Fi :) )
- Try opening the editor again – it will fail
- In your browser's developer tools, disable "Offline" mode (or turn on your Wi-Fi)
- Click "OK" to retry – editor should load
I vaguely recall a case where a similar problem was caused by unbalanced HTML in some overridden localisation message (it would have caused the WT editor to be inside the wrong element, and therefore not be hidden), but I can't find that task either.
Yes, that is the expected behavior. We currently have no way to preserve the content of the reference, and pasting just the link is useless and annoying, so we paste nothing.
My bad, I thought the issue fixed by the previous patch was the only one, but it turns out there's one more issue specific to the reference dialog, which I haven't tested.
@Ryasmeen In new wikitext editor, closing the link inspector to insert an internal link should be instant, and should not display a popup with a progressbar while doing network requests.
OO.ui.ProcessDialog uses OO.ui.Process, and that uses jQuery Promises. This is probably a similar problem to T233480.
Wed, Nov 27
Tue, Nov 26
Mon, Nov 25
I was curious, so I checked. I looked at 10 random moderately-large wikis (from s2).
The test fails because NSFileRepo overrides wgIllegalFileChars to remove the : character from it.
This seems like a good idea to me, but we should actually check roughly what percentage of deletions is done with the default summary (and what percentage with empty summary).
Sun, Nov 24
As a result of these patches, we will no longer display tabs as "➞" in source mode (NWE). They will still be displayed that way in visual mode though.
Sat, Nov 23
Fri, Nov 22
It refers to describing changes in visual diffs. For example: https://test.wikipedia.org/w/index.php?title=User:Matma_Rex/sandbox&diff=409254&oldid=384621&diffmode=visual
I’ll note that in my case (the duplicate task) both icons are cut off (the arrow too), and by a much larger amount.
Tue, Nov 19
You will have to carefully test that this doesn't break any modal dialogs / drawers / etc. that are supposed to prevent the scrolling of the page.
Mon, Nov 18
Is this still a problem? I don't see any such test failing, at least.
Sun, Nov 17
Thu, Nov 14
I just realized that this was filed before T238285, and I should have closed the other task as duplicate. Sorry!
I ran curl -I "https://ban.wikipedia.org/wiki/Mal:;" in a loop for a while to see if this affects particular servers.
This affects all wikis. I could also reproduce with https://en.wikipedia.org/wiki/;, which will either redirect to the article about semicolons, or the main page.
There is nothing wrong with that title. Mal:; is perfectly valid. Similarly, T238276 reports a problem with ;, which is also perfectly valid.
It fails inconsistently for me. It doesn't depend on the browser, I was able to get both of these results in Chrome, and also using curl.
This was filed again as T214790 and implemented! We haven't notice that this task already existed. I'll close it as a duplicate.
This is still a problem (and it affects all browsers). That page changed, so you have to test with this old revision: https://de.wikipedia.org/w/index.php?title=Hilfe:Bilder&oldid=161636983
This was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/441509 "Remove special handling for category and file pages".
I can reproduce this, this may be a similar problem to T220629: Right click to delete across paragraphs in Firefox results in no model transaction.
Wed, Nov 13
I'm not sure if we really have to change this, given that the browser bug was apparently fixed in Chromium 77, but this approach also works correctly, so let's just do it.