This isn't the behaviour on non-VE MediaWiki installations: https://wikitech.wikimedia.org/w/index.php?title=Dell_PowerEdge_1950&action=edit&redlink=1

Perhaps only at SET (Single Edit Tab) wikis?

The "What if I wanted to start that page in the visual mode?" part is more or less T55441: VisualEditor: Where VisualEditor is the primary editor, redlinks in read mode should open VE (not wikitext editor) (i.e. use default editor for redlinks), which is fixed only for SET wikis.
If you want to create the page in your non-default editor, just switch. If you think this takes to long because the editor initializes too slowly, that's T154843: New Wikitext Editor: Major improvement to load time and preview time.
If you are on a red category page and want to see the list of entries in it, that's T139191: VisualEditor makes redlinked category index pages inacessible.

As James said above, clicking a redlink more or less always starts in editing mode, even without VisualEditor, so it's hardly the expected behavior just to show the placeholder for the non-existing page without an editing interface. (Though his example isn't the best. The one exception when no editor is shown after clicking a redlink is when you don't have the permission to create that page, so for me the above link actually does not load any editor.)

Are we sure that opening an editor is the best behavior? Maybe it should take you to "This page doesn't currently exist; you can search this title in other pages or edit this page" first (or local equivalent; see https://en.wikipedia.org/wiki/Elkelkvnelknblekfnbeldkf for enwiki's version).

I think this actually makes sense, but:

1. This will require quite some updating on-wiki, for example, searching for "Elkelkvnelknblekfnbeldkf" brings up the search page containing a redlink that is meant to launch the editor. (https://en.wikipedia.org/w/index.php?search=Elkelkvnelknblekfnbeldkf&title=Special%3ASearch&go=Go) There are probably many other places, where an explicit action=edit would be necessary, if redlinks no longer would launch the editor.
2. It should be discussed with a much wider audience then just the VE component in Phabricator.
3. It has been that way for a very long time, so people very probably will complain about changing this, even if it does make sense.

If you were to add a user preference "Don't open redlinks in edit mode" that applies regardless of the currently configured editor, that would pretty much solve the problem. The interface would just have to not append &action=edit to links that have &redlink=1 in the URI. I have a bit of user JS doing pretty much this exact thing as mentioned in T195914.

(We discussed this in the planning meeting today.)

As written, I would decline this – I think opening the editor for pages that don't exist is a very "characteristic" behavior of MediaWiki, and I would expect that changing this would break some workflows and make users unhappy. If we were to change that, we'd have to do it with a proper process with discussion on Meta and notifications if it is decided (@Schnark summarized this well above), but personally I don't think it's a good idea.

I am not sure if a preference like suggested by @AfroThundr3007730 would be ideal. It would be helpful for some users, but I think it would be awkward for others (from what @Whatamidoing-WMF said, the current behavior is undesirable for her when viewing user pages, but okay for articles).

The real problem here is that on pages that don't exist, the editor can't be closed. The namespace tab is also a redlink (it opens the editor again) and there is no "Read" tab. And these two are the only way to close the editor, since we have no "Cancel" button within VisualEditor itself (T85470).

While the issue is not specific to VisualEditor (the tabs function exactly the same if you use the old wikitext editor), the old wikitext editor has a "Cancel" button, which lets you switch to view mode.

So… a solution would be to either (we could also do more than one of these options):

• Add a "Read" tab to pages that don't exist
  • I think this is the best solution and kind of obvious in hindsight. However, this will not help people using the MonoBook skin (which doesn't have that tab at all).
• Make the namespace tab always open the view mode, not the editor
  • I'm not sure about this. I think that could be confusing when compared to the behavior of the talk tab (which would presumably still open the editor if the talk doesn't exist?).
• Add a "Cancel" button within VisualEditor (T85470)
  • When it was previously discussed, folks felt that it would take up too much space on the toolbar. Personally I think that maybe we could do it anyway? ;) There was also an idea of making "Publish" a dropdown menu with options for Publish/Preview/Changes/Cancel.

I initiated this whole chain of requests (see T195914 and this VPT post that started this one). I am not quite sure what is being discussed anymore.

To clarify the issue and problem: when I hit the Twinkle rollback(AGF)/rollback/rollback(vandal) button two things happen. First, the page reverts the edit back and reloads; second, the offending user's talk page opens in a new tab. The user's talk page now automatically opens in Edit mode, instead of Read mode. This happens for brand new user talk pages and user talk pages with comments already on them. It is not just redlinks. This does not occur with the old wikitext editor, it only happens with the new wikitext editor (VE).

Having to switch between turning VE source editing and an older editor is burdensome for me, I don't know if others feel the same way. Often in anti-vandalism patrolling, you stumble upon new users who do not cite their sources or make a simple mistake in a positive contribution to the project. I could revert that user for lacking citations or any other guideline they did not adhere to, but I fear that it will scare away a clearly good faith editor. VE's automatic citation tool is vastly superior. I am less inclined to assist problematic edits or I can not attend to as many as I would like if I have to switch back and forth. Therefore problematic edits allowed to stand weakens the project. Auto-opening in source mode not only slows down the computer because of VE, but it can make it more difficult to see what level of warning a vandal has received on their talk page, which ultimately slows down anti-vandalism patrolling.

What @AfroThundr3007730 suggested would prevent this sequence of events from occurring.

Seems like additional things are being discussed here, which is fine too.

First off, thanks for looking into this. Now let's dig in.

In T211379#4818145, @matmarex wrote:

I am not sure if a preference like suggested by @AfroThundr3007730 would be ideal. It would be helpful for some users, but I think it would be awkward for others (from what @Whatamidoing-WMF said, the current behavior is undesirable for her when viewing user pages, but okay for articles).

I'm not sure it would be that much of an issue for users, who would just leave it alone if unwanted. Or you could consider adding it as a gadget so the rest of us power users can suppress the editor during our workflows.

The real problem here is that on pages that don't exist, the editor can't be closed. The namespace tab is also a redlink (it opens the editor again) and there is no "Read" tab. And these two are the only way to close the editor, since we have no "Cancel" button within VisualEditor itself (T85470).

Probably not ideal, but in this case, pressing the Esc key will exit the editor and show the placeholder. VE could do a better job of advertising its keyboard shortcuts.

• Add a "Read" tab to pages that don't exist
  • I think this is the best solution and kind of obvious in hindsight. However, this will not help people using the MonoBook skin (which doesn't have that tab at all).

That would be handy in lieu of a way to exit the editor properly, but it would be better if read was the default mode.

• Make the namespace tab always open the view mode, not the editor
  • I'm not sure about this. I think that could be confusing when compared to the behavior of the talk tab (which would presumably still open the editor if the talk doesn't exist?).

Considering the talk tab is technically a namespace tab, I would think it would count as well, and editors would likely expect their behavior to be consistent.

• Add a "Cancel" button within VisualEditor (T85470)
  • When it was previously discussed, folks felt that it would take up too much space on the toolbar. Personally I think that maybe we could do it anyway? ;) There was also an idea of making "Publish" a dropdown menu with options for Publish/Preview/Changes/Cancel.

The dropdown proposal (can't remember the ticket) sounds like the most versatile method without eating up toolbar real estate.

The proposals above don't really target the original issue of preventing the editor from opening in the first place. Yes, there are ways to close it and, sure, we could add another tab to the interface when switching between talk and non-talk, but that doesn't take into account redlinks in other places (e.g. the page body, history, contributions, etc.). This isn't necessarily about speed and resource usage of the editor (even though that should also be considered, as not everyone has a beefy computer).

We've already listed several examples of workflows where opening a page in edit mode (regardless of editor version, wherever the redlink happened) is undesirable. From the top of my head:

• Counter-vandal work and recent change patrolling, where Twinkle does most of the work of rollback and administering a warning to the user's talk page and the editor just gets in the way.
• Account creation workflow (WP:ACC), where we do a lot of userspace checks that may include visiting non-existent talk pages. The editor loading is completely superfulous as I close the tab.
• Plus when I'm welcoming a new user (via ACC or not), it's usually with a pre-built welcome message delivered through Twinkle, and the editor just gets in my way.
• Or more directly relevant to mainspace editing: When I intentionally click a redlink to see the move/deletion log, and the editor quickly drops in offering me the opportunity to create it again.

Essentially, the only way for the editor to spawn would be actually clicking on the edit tab. Be it via preference or gadget, this is something that would be useful to have available without user JS hacks.

In T211379#4819026, @Classicwiki wrote:

To clarify the issue and problem: when I hit the Twinkle rollback(AGF)/rollback/rollback(vandal) button two things happen. First, the page reverts the edit back and reloads; second, the offending user's talk page opens in a new tab. The user's talk page now automatically opens in Edit mode, instead of Read mode. This happens for brand new user talk pages and user talk pages with comments already on them. It is not just redlinks. This does not occur with the old wikitext editor, it only happens with the new wikitext editor (VE).

In the older editor, I think the options Twinkle adds to the URL would have populated and auto-submitted the edit, but the new editor ignores them and presents you with an empty edit window. I have to open the Twinkle tab and "manually" tell Twinkle to send the template in those cases, but it will usually still populate the relevant info, such as article name.

We will get Design input on best way forward based on @matmarex suggestions.