I can reproduce on these pages while not logged in – it looks like this happens because the pages are protected (so I can't edit them as an anonymous users). But in this case we just should not show the links. I filed a separate task: T276393
The issue looks similar to T260584, which is be fixed in 1.36. In the meantime, check any <gallery> tags on the page for invalid filenames and fix them, and the editor should work.
VisualEditor doesn't use $.cookie directly, we use mw.cookie. This error would mean that mw.cookie is loaded, but its dependency $.cookie is not. I have no explanation for how that would happen, but it sounds like potentially a much bigger problem if RL depedencies stopped working.
In T275881 we implemented a small part of this task – reply links will no longer be added inside <blockquote> tags (and also <q> and <cite>).
That fixes it, but I still don't really understand why the issue happens. I've already spent nearly two days on this, and there ar probably other things I should be working on.
I wonder if this is related to T276164. Some other bug causes the selection to be moved to the beginning of the document (not necessarily the special character toolbar one), and then you end up a template at the beginning without realizing it.
I liked the idea of adding _ at the end of such URLs, to achieve compatibility with clients like this without changing our overall URL scheme (T257966#6314839).
Mon, Mar 1
The bug occurs with the special character toolbar because it tries to focus the surface in ve.ui.SpecialCharacterDialog.prototype.getReadyProcess(), which is necessary because OO.ui.Window.prototype.ready() focusses the window itself.
I was planning to work on this, but didn't want to start until we fixed T172694.
Sat, Feb 27
The numbers are off because references used only inside the infobox (and other templates) are counted separately.
Icons in grouped notifications are 21x21:
As a bonus, this will fix problems with signatures of users who add formatting to the timestamp:
Fri, Feb 26
I had a closer look at this problem, since this error implies that DiscussionTools' parser detected a comment that consists of no DOM nodes (and we get this error when trying to check which source page these DOM nodes are transcluded from). Filed another task about this: T275934: Duplicate reply links appear for some comments with two signatures
This is not enabled for Wikimedia wikis yet. We will need to make a config change to set $wgDiscussionToolsEnable2017Wikitext = true;.
@ppelberg It's specifically related to the unique topic identifiers (T264885#6859503). If we use the time the topic was published as a part of the identifier, then adding a reply that quotes a comment from an older thread could change the thread's identifier (by using the time of that quoted comment, instead of the oldest "real" comment in the thread), thus breaking subscriptions that used the previous identifier.
I agree that we should do this. The idea was raised before in T249293, but we haven't gotten around to implementing it.
Thu, Feb 25
Oh, sorry, I think I misunderstood. You're saying that step 5 occurs like in the bug report (arrow keys switch modes while the mode selector is active), but step 6 does not (arrow keys work normally in the editor).
On which wiki have you tested? It works correctly for me on https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Main_Page. The patch is not yet deployed to production wikis (this will happen next week).
Removing hover would be a usability regression too.
The same issue can be reproduced on other wikis, e.g. English Wikipedia: https://en.wikipedia.org/w/index.php?search=QINU
Here's the scenario I'm imagining:
This has nothing to do with subpages, or with VisualEditor. mw.Uri crashes when there's an un-encoded '%' character in the URL. This is the exact same issue as T269948 or T268060. It should be tracked and fixed as a bug in mw.Uri, not in a hundred random extensions that use that code.
How should the state of the dropdown be indicated instead?
Wed, Feb 24
I dusted off my patch from December, and set up the demo wiki linked above. For testing, I imported the edit notice from https://en.wikipedia.org/wiki/Talk:Main_Page to https://patchdemo.wmflabs.org/wikis/1469c4ab766b236d440e43dc73bfe977/w/index.php/Talk:Main_Page (it's particularly bad).
I think this task is done, and further work to make edit notices appear in DiscussionTools would happen in T269033.
(not testable on Wikimedia wikis, since we've always used configuration variables that worked around the bug)
No, it does not. The removed code allowed us to change the default value of the 'visualeditor-enable' preference for new users, without changing it for existing users. However, we do not actually use that preference for rolling out VE these days (it has been re-used for the beta feature, and I don't think we'd ever want to enable a beta feature by default…).
That is a very minimal fix – it will just hide the loading bar and display an error message when appropriate.
Out of the bugs I listed, the only unresolved one is T242327. I closed all the others.
Indeed looks resolved. I don't see the markers in any of the pages linked on this task.
Seems to be a real issue with math tags, and not fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/655884 as I was hoping.
I asked @ashley to check this one (since I don't have VoteNY running locally) and he says this patch indeed fixes the issue.
I think this has been fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/655884.