Page MenuHomePhabricator

On redirect pages, "article" tab in top bar should lead to nonredirected page (&redirect=no)
Open, LowestPublic

Description

Author: creidieki+wikibugs

Description:
Steps to reproduce:

  1. Look at a redirect page, using &redirect=no to see the actual redirect.
  2. Click on "Edit this page" on the top bar.
  3. Click on "Article" on the top bar.

You would expect to be taken back to the redirect page (with &redirect=no), but
you're instead taken to the target of the redirect.

This also works with any of the other tabs ("Discussion", "History", etc.) in
step 2.

This has been annoying when attempting to categorize redirects, etc.

Bounty: I will happily send $10 to a developer who fixes this bug. I usually
use PayPal, but I could try something else.


Version: unspecified
Severity: minor
URL: http://en.wiktionary.org/w/index.php?title=Transwiki:Side_chain&redirect=no

Details

Reference
bz3324

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:49 PM
bzimport added a project: MediaWiki-Redirects.
bzimport set Reference to bz3324.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 31 2005, 1:35 PM

creidieki+wikibugs wrote:

I was asked on MediaWiki-General to clarify why I think this is a bug.

I basically think that this violates user expectations. This bug will only
occur when a user is dealing with a redirect itself. That is, they are
currently editing a redirect, posting on the redirect's discussion page, or
viewing the redirect's history. In these cases, the user is thinking
specifically *about the redirect*. So, if they want to come back to the page
they were looking at before, I think it should be the redirect itself.

Fixing this bug shouldn't affect any user who isn't actively dealing with
redirects. On the other hand, it should make things a lot easier for those
users who edit a lot of redirects (I've personally been categorizing redirects
lately).

brion added a comment.Aug 31 2005, 8:23 PM

On the other hand this would complicate some tasks, such as testing that the redirect
works -- you'd have no way to do so except to edit the URL manually.

gangleri wrote:

(In reply to comment #0)

You would expect to be taken back to the redirect page (with &redirect=no), but
you're instead taken to the target of the redirect.
This also works with any of the other tabs ("Discussion", "History", etc.) in
step 2.
This has been annoying when attempting to categorize redirects, etc.

(In reply to comment #2)

On the other hand this would complicate some tasks, such as testing that the

redirect

works -- you'd have no way to do so except to edit the URL manually.

At
http://en.wiktionary.org/w/index.php?title=Transwiki:Side_chain&redirect=no
you can click on "Permanent link"
http://en.wiktionary.org/w/index.php?title=Transwiki:Side_chain&oldid=459760
to verify the rendering.

I think this is a fair "workaround".

best regards reinhardt [[user:gangleri]]

Huji added a comment.Sep 28 2007, 3:04 PM

With the recent changes to the message shown after a redirect, it now has a link to the redirected page with &rediret=no in it, and a link to the destination page. Having this, I think the changes asked in this bug are no longer required. Thus, I'm marking it as FIXED.

Huji added a comment.Sep 28 2007, 3:12 PM

As "FIXED" is regularly used when a change is made to fix the bug, I'm changing it to "INVALID".

brion added a comment.Sep 28 2007, 3:43 PM

I have no idea what comment #4 and 5 refer to, but the described issue seems to be entirely unchanged. Reopening.

brion added a comment.May 29 2008, 4:56 PM

Marking as WONTFIX; my original impression that current behavior is desirable still stands.

Retro added a subscriber: Retro.May 10 2019, 1:37 AM

Reading the previous comments, I'm not clear that the original reasons for closing this actually address this report's request directly. To reply to Brion's comment, one can test a whether a redirect works as expected by clicking the large link that the redirect page produces. To reply to Huji's comment, the links that the redirect page generate when the redirect is created are irrelevant to the links accessed when switching between tabs; these are two entirely separate workflows.

As far as I can tell, there is no advantage to immediately going to the target page after switching to the Page or Read tabs. One can only access these tabs from other tabs, and when I am in the Edit, Talk, or History tab, I am already examining the redirect in more detail, usually in preparation for editing it. In fact, I cannot think of a single instance where I wanted to go directly to the target page when I clicked on the Page or Read tab.

While this can easily be partly solved by the user script posted here, I still think it would beneficial if this was the core behavior. This would also make the interface more consistent; one is not taken to a redirect page's target after saving and editing, so I think the the Page and Read tabs should behave the same.

I'm boldly re-opening; others are welcome to revert if they disagree.

Retro reopened this task as Open.May 10 2019, 1:37 AM
Izno added a subscriber: Izno.May 10 2019, 12:47 PM
Scott added a subscriber: Scott.May 10 2019, 12:49 PM
Ahecht added a subscriber: Ahecht.May 15 2019, 10:05 PM

I would agree that the intended behavior of the "Article" button, when on a talk/history page of a redirect, should be to link to the redirect itself. The number of times an editor wants to go directly from the redirect talk page to the redirect target is small compared to the number of times the editor wants to go to the redirect itself.