It appears that this is now fixed, with the create option also applying to protecting it.

In T306320#7860406, @Bugreporter wrote:

Before fully removing it we can first hide the link in sidebar.

Reverted rename because I didn't feel like it was my place to rename it, just starting out here and not really sure what I'm doing yet. Though, it sounds like me and @Reedy were essentially saying the same thing, so did you want to carry it out?

So far as I know, it already is deprecated, the question is when to remove it. Correct me if I am wrong; I assume @Aklapper has thoughts on a potential date?

But it hasn't been triaged

Actually, it looks like this only affects Monobook. For Vector users, there is no "wikilove" tab, but instead a heart icon which *does* disappear with JS off.

The steps to reproduce should have been obvious from my original post, but sure:

@Aklapper That comment has absolutely nothing to do with this task. Did you copy and paste it from somewhere?

@Aklapper So I've measured it locally and there is no speed difference in edit stashing, it's just a feature that creates more problems.

But the entire premise of edit stash is a problem. That's why there needs to be a config (or just remove it completely)

It's not just one specific type of wikitext. It's the concept of the edit stash feature as a whole. Because during that time between stash and real save, the render output could change, and in my case it did, leading to a nonexistent output, and even after I purged the page is now in maintenance categories for hours. That's why edit stash should be disableable.

In T301178#7691104, @Aklapper wrote:

What's your specific use case and example for disabling it?

So, if people need to remove edit stashing you expect them to just directly hack on the core? There was nothing wrong with that configuration option, and actively needs to be disabled for us

I'd argue it's the opposite. I explained why it should be added in the OP, yet there was no clear reason for removing it ("use case for disabling this is very marginal" is not true and tells nothing)

https://phabricator.wikimedia.org/T301178

@Aklapper There's a feature where when you start typing an edit summary MediaWiki will send a request in the background to start rendering the page, called "edit stash". The config to toggle this feature was removed for discernably no reason, and should be put back so people can disable it if need be.

Ten tasks away from 3 million

This seems to be fixed now

Yesterday this happened on Meta but not enwiki, but today it is happening on both Meta and enwiki. In accordance with the weekly deploy system, that means it was likely caused by this week's update

This turned out to be due to edit links being added with a sysop-show div at https://en.wikipedia.org/w/index.php?title=Main_Page&diff=987899553&oldid=986033447 - so this can be closed

For what it is worth, I do not see an edit link there. While at first I thought this was because I am not a sysop on enwiki, I copied the contents of the main page into the sandbox at https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=987964125 and did not see an edit link there either. It may be a client issue. Izno, can you try reproduction on other devices?

A demonstration of this bug is now available at https://test.miraheze.org/wiki/User:Dmehus/Create_protection_known_issue

In T259562#6476028, @Ammarpad wrote:

In T259562#6475267, @Naleksuh wrote:

Finally this task is getting some attention

I'd not advise you to wait for this to be added in core, if you truly need it. Because that could take forever to happen. Please explain why you cannot use the TitleGetRestrictionTypes hook that I mentioned above, to achieve the same thing for your install.

Finally this task is getting some attention

In T207701#4979419, @ToBeFree wrote:

Interesting, possibly related, HG 3.4.4. Clearly a technical issue, proven by the edit summary: https://en.wikipedia.org/w/index.php?title=Jason_Kenney&diff=884940008&oldid=884939997

Also, the current thanks log only shows who thanked who. Why does it not list which edit/logaction was thanked for?

In T257095#6278379, @Aklapper wrote:

@Naleksuh: Thanks for reporting this! Could you please edit the summary to describe an actual problem and your proposal? Also see https://www.mediawiki.org/wiki/How_to_report_a_bug - Thanks :)

Does appear to be fixed, likely caused by Thursday™

I was initially logged in, but can't edit due to session data. I try signing out, can't sign in. IPs can still edit though, take your pick on if that's good or bad.

This is actually on all wikis

Good idea, could say [rollback] like how it did before edits were counted

Since this is a relatively minor bug anyway, I would prefer to leave it until it's actually found out why it counts as 0. If it actually prevented the edit from being rolled back, that would be one thing, but it's not.

In that case, what happens if it should show 2. Does it show 1? Or does this bug only happen when for a single edit? All questions I don't have the answer to as I've only encountered it once, but necessary for a good and permanent fix

Danny's change seems to just change 0 to 1. I'm not entirely sure if that fixes it, though, for example what happens if you're really trying to rollback 2 edits, does that say 2, 1, or 0, or something else? I see nothing wrong with the quick hack as, but would it actually fix the problem? Because if 2 gets calculated to 0, then this code will change it to 1, when it should have been 2. Can anyone confirm what happens when rapidly rollbacking and then coming across multiple edits (if that's even what causes it)

Hello. I also encountered this bug while having to rollback around 50 edits. it said [rollback 0 edits] when it should be [rollback 1 edit]. Like the creator of this bug, I was also doing large edits. I don't see the connection between that and 0 instead of 1, but it is true. I am unsure if it always says 0, or just flickers about a little, as I was only reverting a single edit in all cases.

In T250393#6102452, @Naleksuh wrote:

There should be seperate options for font in editing space and fonts in diffs, with the default being monospace and sans serif respectively

There should be seperate options for font in editing space and fonts in diffs, with the default being monospace and sans serif respectively

Congratulations on the new update! Now all you need is a way to turn it off and you'll be all set :)