Page MenuHomePhabricator

Purge makes the read tab inactive
Closed, DeclinedPublic

Description

Author: nykevin.norris

Description:
Screenshot of inactive tabs (cropped)

Look at [[Main page]].
Now purge the main page so the url has action=purge in it.

In both cases look at the "Read" tab in Vector. In the second case, the read tab will have the same visual style as the "Edit" and "History" tabs (i.e. it will be inactive or "not selected")

Obviously this is not specific to the main page.

Purging should leave the Read tab active, since, for all intents and purposes, the user is still reading.


Version: unspecified
Severity: trivial

Attached:

Screenshot-1.png (59×135 px, 5 KB)

Details

Reference
bz26034

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:15 PM
bzimport set Reference to bz26034.
bzimport added a subscriber: Unknown Object (MLST).

Fixed in r80201 for all content_navigation using skins (ie: Vector in 1.18).

The tabs are for actions.

When viewing the article wgAction= view. When lookig at the history it's wgAction=history.
When purging the cache the wgAction=purge.

There's many different actions, some by extensions some by core. But I think going down the path of manually giving 1 action-tab multiple actions is not a good idea.

See for example the following case: http://i.imgur.com/pWqEn.png
Where there is a Purge-tab. If this makes it into a release you're looking at:

bug: Action=purge wrongly highlights the Read-tab.

Whatever the chosen action is, despite what is entered in the URL, should be highlighted. The problem here is that we have logic somewhere saying "purge, ok, I can do that", then logic somewhere else saying "purge? never heard of that, you must mean read!" and yet more logic later on saying "what action are we using? I'm gonna highlight something..."

What we need to do is ensure that whatever the interpretation of the action parameter ends up being is reflected in the UI. This is a dirty hack to help fake that, but it's not setting a dangerous precedence as far as the UI is concerned.

Also, a purge tab is a bad design - purge is not a mode, it's an action - it should be an item in the drop down like protect or move.

Closing again. If you re-open, make sure to retitle this properly.

I won't re-open.

(In reply to comment #4)

purge is not a mode, it's an action - it
should be an item in the drop down like protect or move.

I agree. For an end-user purge does not belong in the list of: view, edit, history etc. (modes, views or "p-views")

Although technically "purge" is as much an action as view, edit, history, delete etc. is. (atleast when checking the URL and wgAction). But that's behind the scenes.

In the UI, if a Purge tab is added by whatever script, it should be in the dropdown (p-actions).

(In reply to comment #5)

Closing again. If you re-open, make sure to retitle this properly.

It looks like it wasn't closed after all.

But I am closing it now, as WORKSFORME. The purge action now redirects to the view action, so this is pointless.