Last modified: 2011-03-13 18:05:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3324 - On redirect pages, "article" tab in top bar should lead to nonredirected page (&redirect=no)
On redirect pages, "article" tab in top bar should lead to nonredirected page...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
unspecified
All All
: Lowest minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wiktionary.org/w/index.php?...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-31 13:35 UTC by M. Creidieki Crouch
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description M. Creidieki Crouch 2005-08-31 13:35:58 UTC
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.
Comment 1 M. Creidieki Crouch 2005-08-31 14:05:53 UTC
I was asked on #mediawiki 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).
Comment 2 Brion Vibber 2005-08-31 20:23:18 UTC
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.
Comment 3 lɛʁi לערי ריינהארט 2006-02-08 12:46:26 UTC
(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]]
Comment 4 Huji 2007-09-28 15:04:11 UTC
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.
Comment 5 Huji 2007-09-28 15:12:58 UTC
As "FIXED" is regularly used when a change is made to fix the bug, I'm changing it to "INVALID".
Comment 6 Brion Vibber 2007-09-28 15:43:57 UTC
I have no idea what comment #4 and 5 refer to, but the described issue seems to be entirely unchanged. Reopening.
Comment 7 Brion Vibber 2008-05-29 16:56:45 UTC
Marking as WONTFIX; my original impression that current behavior is desirable still stands.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links