Page MenuHomePhabricator

Suddenly whisked off to a different page
Closed, InvalidPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
We read a couple lines. Our brains are digesting what we are reading. And then suddenly we are swept off to a different page without our consent.

What should have happened instead?:

At least ask the user if they want to visit the other page.

Event Timeline

I think this is an intended feature, not a bug.

Though, I can't work out what's causing it.

@Jidanni: Please follow https://www.mediawiki.org/wiki/Help:Locating_broken_scripts before reporting any further issues in Wikimedia Phabricator. Thanks.

I posted https://en.wiktionary.org/wiki/MediaWiki_talk:Common.js#My_fault? because I just checked and the problem even happens for non-logged in users.

@Jidanni -- if you don't like it try this:

  1. Disable JavaScript in your browser; just for Wiktionary.com should be OK.
  2. OR Add the following code to your custom.js:
if (window.disableAutoRedirect) return;

(I haven't tested it, but it should work)

And also...

  1. If you are going to post to https://en.wiktionary.org/wiki/MediaWiki_talk:Common.js don't be vague in describing your complaint. What does https://en.wiktionary.org/wiki/MediaWiki_talk:Common.js#My_fault%3F even mean? What exactly is your problem? What exactly do you want?

All I am saying,
is that the innocent public, not logged in or anything,
using a standard browser, "Chrome",
will see weird behavior, that I reported.

And I am being blamed for filing a frivolous bug report.

It doesn't matter if I don't like it or not.
I am saying it looks unexpected to the general public.

Fine. I will fix my note on that talk page.

@Jidanni --

What you think of as "weird behavior" is a feature that a Wiktionary editor has deliberately implemented on Wiktionary. Presumably that editor thinks it's a benefit to the "general public." But, they must abide by consensus on Wiktionary, so the place to comment on that is Wiktionary, not here.

This is not a "frivolous bug report;" it's an invalid bug report because (1) it doesn't concern MediaWiki core or extensions, and (2) it's not a bug.

And you still haven't really specified enough detail in your complaint at https://en.wiktionary.org/wiki/MediaWiki_talk:Common.js#Some_problem_that_I_don't_understand

@Jidanni

My apologies. I now realise you were being vague because you didn't understand. The code that offends you is this:

// == "Did you mean" auto redirect ==
/**
 * This will redirect in 3 seconds if a link enclosed in id="did-you-mean"
 * is found, and add the text "Auto-redirected from X" under the top header
 * if a rdfrom is passed in the get parameters.
 * Pages with wynn ([[ƿ]]) will be redirected immediately.
 **/

$.when(mw.loader.using(["user", "mediawiki.util"]), $.ready).done(function () {
	if (window.disableAutoRedirect) return;

	var rdFromValue = mw.util.getParamValue("rdfrom");
	if (rdFromValue) {
		$("#siteSub").after(
			$("<div>")
				.attr("id", "contentSub")
				.append(document.createTextNode("(Auto-redirected from "))
				.append(
					$("<a>", {
						href: mw.util.getUrl(rdFromValue, { redirect: "no" }),
						addClass: "new",
					}).text(rdFromValue)
				)
				.append(document.createTextNode(")"))
		);
	} else {
		// Redirect as quickly as possible from [[ƿ]] title to [[w]] title.
		var pageTitle = mw.config.get("wgTitle");
		var isWynnTitle = /ƿ/i.test(pageTitle);
		var didYouMean = $("#did-you-mean a").html();
		var target = didYouMean
			? didYouMean
			: isWynnTitle
			? $("#go-to-search-page a").html()
			: null;
		var timeout = isWynnTitle ? 0 : 3000;
		window.setTimeout(function () {
			var canRedirect = mw.util.getParamValue("redirect") != "no";
			var action = mw.config.get("wgAction");

			if (
				target &&
				target !== pageTitle &&
				canRedirect &&
				!window.disableAutoRedirect &&
				(action == "view" || (isWynnTitle && action == "edit")) &&
				mw.config.get("wgArticleId") === 0 &&
				mw.config.get("wgNamespaceNumber") === 0 &&
				!/Redirected from/.test(jQuery("#contentSub").html())
			) {
				window.location = mw.util.getUrl(target, { rdfrom: pageTitle });
			}
		}, timeout);
	}
});

As you can see if you read it, it counts 1 Mississippi, 2 Mississippi, 3 Mississippi, then if Javascript hasn't fallen over yet, it grabs the user and "whisks them away" to the "actually, did you mean...?" page.

DCDuring reopened this task as Open.EditedMay 30 2025, 2:12 PM
DCDuring subscribed.

The behavior complained about is a concern, perhaps a minor one, perhaps hard to alter. Normally a search term with lower case initial letter where there is no pagename in lowercase, but there is one in uppercase will quickly take the user to the uppercase. In this case, the user is first taken to the lowercase pseudopage because the entry had been deleted. The normal behavior is effectively like that of a hard redirect, which is not as unsettling as this behavior. A normal user does not need to see the deleted page at all. A regular contributor seeking to add the 'missing' page or see what had happened to it would know to click on the autoredirect link.

Maybe we need to have a new ticket with a different "what should have happened instead": User should be redirected without delay.

Izno subscribed.

Issues with arbitrary onwiki Javascript are not tracked in Phabricator in general. It is found at en.wikt MediaWiki:Common.js line 226. You may followup at the talk page there.