Hi, could you please include a full list of steps that someone would have to perform to reproduce this situation (including links that other people could use), what is expected to happen (including the full URL that you'd expect to end up on), and what happens instead (see https://www.mediawiki.org/wiki/How_to_report_a_bug )? Thanks! :)

Ah, I think I understand the problem. This seems to be meta specific (cannot reproduce on mw.org with the same account permissions).

1. Go to https://meta.wikimedia.org/w/index.php?title=User:YOURUSERNAME/Sandbox&action=edit
2. Paste the following input:

<inputbox>
type=create
hidden=yes
prefix=User:YOURUSERNAME/{{#titleparts:{{PAGENAME}}|2|2}}/Subsandbox
buttonlabel=Whatever
</inputbox>

3. Press Show Preview
4. Click Whatever button
5. Get redirected to main page (unexpected)
6. Go to https://www.mediawiki.org/w/index.php?title=User:YOURUSERNAME/Sandbox&action=edit
7. Repeat steps 2-4
8. End up instead on https://www.mediawiki.org/w/index.php?action=edit&title=User%3AYOURUSERNAME%2FSandbox%2FSubsandbox&create=Whatever (expected)

More simplified, ignoring <inputbox>:
https://www.mediawiki.org/w/index.php?action=edit&prefix=User:Malyacko%2FSandbox works.
https://meta.wikimedia.org/w/index.php?action=edit&prefix=User:Malyacko%2FSandbox does not work; it redirects to Main_Page.

@Aklapper Thank you so much for your help with this, including guidance about what information to include. It seems like you were able to determine and describe the problem and how to replicate it. Is there still information you need from me about that at this point? @I_JethroBT has a better understanding of the issue than I do, so I'm including him in case he wants to add anything.

I'd recommend to go on IRC and ask in #wikimedia-tech and/or #mediawiki-dev if someone has an idea and could take a look at this issue.
Maybe someone will also stumble upon this ticket itself, but WMF-General-or-Unknown is a quite broad project tag.

I myself don't need more info and I'm afraid I cannot help further. :-/

@Aklapper I think I understand now that you are just here to generously help me out with making this ticket functional. Thank you! I appreciate it. I just sent a message to #wikimedia-dev using Element. Thanks for that tip. Helpful.

Adding the inputbox extension tag here, as I suspect it is centrally involved with the unexpected behavior described.

Also see T269230: Inputbox with option type=comment produces pages in main namespace which is about a very different parameter but has a similar outcome (ending up in the top-level mainspace).

@KEchavarriqueen: You can do so (and it's likely correct), but note that changing the Priority field will not automagically change anything (fields summarize and reflect reality and do not cause it). See T268696#6649137 how I'd recommend to get attention of some developers if you want to see this closer to getting fixed.

Or to be more explicit: Creating a ticket here (if that is meant by "flagging"?) does not necessarily mean that some developer will decide to take a look and investigate. As far as I know nobody is looking into this, hence no updates or dates. (Please see also Development prioritization for general info - thanks.)

Furthermore, the InputBox extension (if that's the culprit) currently has no code stewards/maintainers.

I was also annoyed by this issue so I went ahead and investigated. For starters, I cannot reproduce it locally, where I get the same result as on mw.org.

Second, handling the "prefix" parameter happens inside InputBox, specifically within the onMediaWikiPerformAction handler, which looks fairly simple. There are three things that could cause the hook to fail:

1. If the current action is not "edit". Although we're correctly passing action=edit, MediaWiki::getAction() has some additional logic, so it's still remotely possible that something's broken there, but for now I'm going to assume that this is not the cause.
2. If the "prefix" parameter is not passed. This is certainly not the case.
3. If the OutputPage::redirect() call doesn't work for some reason. This would require some investigation.

I should also note that no redirect happens at all, apparently. The code is supposed to return a 301 status code, but:

$  curl -Is 'https://meta.wikimedia.org/w/index.php?prefix=FOOOOOOOOOO&action=edit' -w "%{http_code}" -o /dev/null
200

Also, since it happens for meta but not other wikis, it might have to do with site config, or custom hook handlers. In general, this isn't easy to investigate given the local non-reproducibility.

I've also tried the corresponding URL on various WMF projects (a few wikis, + commons, +species, +wikiquote), and for all of them, it works. For instance:

$  curl -Is 'https://it.wikinews.org/w/index.php?prefix=FOOOOOOOOOO&action=edit' -w "%{http_code}" -o /dev/null
301

There's something special for meta going on, but I don't know what exactly. We might need to check custom hook handlers, and possibly live-hack a prod server (or at least run a REPL there), because I really have no idea as to what makes meta special.

This is a very interesting bug. I was playing with var_dump at mwdebug1001. This is my new version of the hook in inputbox i used for testing:

public static function onMediaWikiPerformAction(
        $output,
        $article,
        $title,
        $user,
        $request,
        $wiki
) {
        if ( $wiki->getAction() !== 'edit' && $request->getText( 'veaction' ) !== 'edit' ) {
                // not our problem
                return true;
        }
        $mainReq = RequestContext::getMain()->getRequest();
        var_dump([
                'mainReqFoo' => $mainReq->getText( 'foo', 'bar' ),
                'passedReqFoo' => $request->getText( 'foo', 'bar' ),
                'prefixMain' => $mainReq->getText( 'prefix', 'bar' ),
                'passedReqPrefix' => $request->getText( 'prefix', 'bar' ),
                'valuesPassedReq' => $request->getValues(),
                'valuesMainReq' => $mainReq->getValues(),
        ]);
        if ( $request->getText( 'prefix', '' ) === '' ) {
                // Fine
                return true;
        }

        $title = $request->getText( 'prefix', '' ) . $request->getText( 'title', '' );
        $params = $request->getValues();
        unset( $params['prefix'] );
        $params['title'] = $title;

        global $wgScript;
        $output->redirect( wfAppendQuery( $wgScript, $params ), '301' );
        return false;
}

And this is what I got with curl:

urbanecm@notebook  ~
$ curl --silent -H 'X-Wikimedia-Debug: backend=mwdebug1001.eqiad.wmnet' 'https://meta.wikimedia.org/w/index.php?foobar=foo&prefix=prefixvalue&action=edit' | head -n 20
array(6) {
  ["mainReqFoo"]=>
  string(3) "bar"
  ["passedReqFoo"]=>
  string(3) "bar"
  ["prefixMain"]=>
  string(3) "bar"
  ["passedReqPrefix"]=>
  string(3) "bar"
  ["valuesPassedReq"]=>
  array(1) {
    ["action"]=>
    string(4) "edit"
  }
  ["valuesMainReq"]=>
  array(1) {
    ["action"]=>
    string(4) "edit"
  }
}
urbanecm@notebook  ~
$

Something has eaten the GET parameters, causing the hook to think it was not set at all. Why?

According to my further tests, $_GET is in correct state. Something in our request classes ignores parameters.

With the help of eval.php on metawiki, I finally understood what's going on and why it's basically only reproducible on metawiki.

The code in the main MediaWiki class will determine the title of the current request before running the PerformAction hook, which makes sense. At a quick glance, it seems to me that the relevant logic is duplicated in several places, but that's unrelated. Since our request has no known title-related parameter (e.g. "title", "oldid", "diff" etc.), it will fallback to the main page. This also makes sense.

Now, let's put the above statements aside for a minute, and let's go inside performRequest(). This method also does some title normalization, but it doesn't affect our case, and $title is still the main page. Then it has a block for handling redirects, title-less URLs etc., introduced by

elseif ( !$this->tryNormaliseRedirect( $title ) ) {

which is always entered in our example, for all wikis (because action=edit will make tryNormaliseRedirect return false). It then checks whether the title is a redirecting special page, and if it is, it will override the main Request object with a DerivativeRequest. While I didn't realize it the other day, it's now clear that DerivativeRequest can discard GET and POST data (see class doc); I was confused by the WebRequest parameter, which is however partially ignored. Since this DerivativeRequest is created with ad-hoc query data (in particular, the data provided by the aforementioned special page), it does indeed lose the GET params. This gets passed to the hook, which doesn't find the "prefix" parameter, and everything fails.

A similar scenario was already on my mind, and perhaps yours, since I started investigating this bug. However, if you followed me above, you might be thinking (at least I was): "but that can only happen if the title is a special page, and we said the code was using the main page". But as you might have guessed by now, especially with you're familiar with meta, here is the crux, and the reason why this issue is only reproducible on meta: the main page there is Special:MyLanguage/Main Page! :)

I'm currently working on a solution.

Change 668697 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/InputBox@master] Process the "prefix" query param in onBeforeInitialize

https://gerrit.wikimedia.org/r/668697

Change 668697 abandoned by Daimona Eaytoy:

[mediawiki/extensions/InputBox@master] Process the \"prefix\" query param in onBeforeInitialize

Reason:

Doesn't seem to work.

https://gerrit.wikimedia.org/r/668697