Page MenuHomePhabricator

Classic toolbar should not be enabled on .js and .css pages
Closed, DeclinedPublic

Description

I noticed that WikiEditor is displayed on .js and .css pages (T26713), but the old toolbar is not being displayed at all (i.e., when "Enable enhanced editing toolbar." is not checked - as is recommended on Wikisource projects because of T30574).

I think the behavior should be consistent among both types of toolbars:

  1. Display the selected edit toolbar whenever the user is editing a page (be it a js page or not); OR
  2. Do not display any of the toolbars when editing .js/.css pages

I would prefer option (1).


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24151
https://bugzilla.wikimedia.org/show_bug.cgi?id=24041
https://bugzilla.wikimedia.org/show_bug.cgi?id=45850

Details

Reference
bz29908

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz29908.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Jul 15 2011, 4:54 PM

Eh? Is there a bug about killing the old toolbar. We really should.

Bug 28856 is about moving it into an extension, but I think it will not be killed...

Change 141293 had a related patch set uploaded by TheDJ:
Toolbar: Only show on WikiText pages

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

TheDJ added a comment.Jun 22 2014, 2:10 PM

The above patch makes the (old) toolbar presence consistent to only show on wikitext content model pages.

Change 141293 merged by Mwalker:
Toolbar: Only show on WikiText pages

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

Resolved? Not resolved?

GOIII added a comment.Aug 17 2014, 8:31 AM

(In reply to Bartosz Dziewoński from comment #6)

Resolved? Not resolved?

Don't think so. See Bug 69447 for starters.

Change 156009 had a related patch set uploaded by Helder.wiki:
Revert "Toolbar: Only show on WikiText pages"

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

Change 156009 merged by jenkins-bot:
Revert "Toolbar: Only show on WikiText pages"

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

He7d3r added a comment.Sep 1 2014, 2:24 PM

Apparently the intention is to not show the toolbar in these cases (i.e. option (2) of comment 0).

The patch has been reverted, back to drawing board.

We need a way to let extensions decide whether the toolbar should be displayed on pages they manage. It seems there are two competing solutions pending:

(Quoting Helder from bug 69447 comment 21)

  1. Create a function shouldShowToolbar which returns true if the content model is wikitext (extensions would subclass EditPage I think): https://gerrit.wikimedia.org/r/#/c/157054/1/includes/EditPage.php,unified
  2. Create a hook to allow extensions to redefined the value of the variable $showToolbar: https://gerrit.wikimedia.org/r/#/c/120357/6/includes/EditPage.php,unified

I can help review and merge, but don't ask me to decide which makes more sense :)

GOIII added a comment.Sep 1 2014, 10:53 PM

(In reply to Helder from comment #10)

Apparently the intention is to not show the toolbar in these cases (i.e.
option (2) of comment 0).

I'm not certain we can soundly reach any conclusions here until Bug 30795 is addressed and/or resolved first. The "confusion" over the now apparent, poorly labeled User: preference ' Show editing toolbar ' leads to different assumptions and or conclusions when considering the issue at hand.

Some believe deselecting that option should equate to disabling the generation of any toolbar at all - be it 'classic', 'enhanced' or whatever the future may bring. Others believe (correctly) the option only controls the generation of the 'classic' toolbar and is independent or overridden by the User preference that immediately follows it, ' Enable enhanced editing toolbar' (also known as the WikiEditor extension-generated toolbar). Still others are swayed by the internal coding terminology in use, ' usebetatoolbar ', as the rationale to champion the 'classic' toolbar over the other(s) while the opposite know not to place so much weight on the term 'beta' at all and, rightly or wrongly, keep an eye towards VisualEditor becoming the "standard" one day. Sharper differences can be drawn from those basics as well. Even the usurpation of Bug 24713 by Bug 24041 (duplicate) has implications towards "defining" this bug.

So while I personally prefer something along the lines of what I THINK option (1) of comment 0 means, I can't be 100% sure about it until Bug 30795 is addressed. And I don't think any of the semi-related bugs that are a variation on the theme of this one should be acted upon until that happens either.

GOIII added a comment.Sep 2 2014, 12:14 AM

(In reply to Bartosz Dziewoński from comment #11)

The patch has been reverted, back to drawing board.

We need a way to let extensions decide whether the toolbar should be
displayed on pages they manage. . . .

Why can't we instead make a User preference option (disabled by default) under the 'Appearance' tab, 'Skin' section that toggles the generation of a toolbar in the those .js/.css situations regardless of having the 'sysop' bit (for MediaWiki: namespace .js/.css) or just being a plain-old registered User (for User: namespace .js/.css)?

This way, the option for which buttons can appear in what namespace under whatever toolbar [or not] is remains open for the "experienced" User(s) to manipulate as needed while still being mindful of the "newbies" and the trouble they can get into by fudging-up their .css or .js files accidently. At the same time, the combination of possible editing preferences in place on the 'Editing' tab, 'Editor' section (e.g. 'Classic' [this Bug] vs. WikiEditor [Bug 24041]) play no role either way in resolving the specific issue at hand to boot.

I've never believed in "push" solutions that minimizes User choice; it frequently minimizes User responsibility in the process as well. Take the toolbar away for X reason(s) and you're the 'bad guy' for infringing upon a contributor's "perceived rights". Let the contributor hang themselves by enabling something they didn't know how to use in the first place and there is no 'bad-guy' to blame but themselves.

TheDJ added a comment.Nov 30 2014, 2:39 PM

my idea was to have editor extensions register themselves as providers of an editor for arrays of content models, then show those as options to the user prefs, and have the user prefs decided which toolbar to show for which content model.

That is partly based on moving the 'classic' toolbar out of core and into it's own extension. It's quite a bit of work.

He7d3r updated the task description. (Show Details)Nov 30 2014, 3:08 PM
He7d3r added a project: JavaScript.
He7d3r set Security to None.
TTO closed this task as Declined.Oct 16 2018, 1:05 AM
TTO added a subscriber: TTO.

The old toolbar is going away.