[Regression] RTL with IE-7 (or IE 8/9 in "compatability mode") does not show any toolbar
Closed, ResolvedPublic

Description

with version 1.19, the default for toolbar is the "beta" toolbar.
however, with RTL, the minimum IE version for using the beta toolbar is 8 (in LTR the minimum version is 7).

so with IE 7, ie 8 in compatability mode, or ie-9 in compatability mode, RTL wikis should fall back to "old" toolbar. this is what happened in 1.18, but this automatic fallback does not work any more in 1.19.

registered users can at least disable the beta toolbar in preferences, and get the old toolbar, but anons don't even have this option, and are left with no toolbar whatsoever.

also, most registered users who use ie7 on RTL wiki do not even realize there is such a thing as the beta toolbar, and are not aware that in their preferences it is set to "on" until the upgrade to 1.19 hit them with this bug.

REPRODUCTION INSTRUCTIONS:
(i do not have access to ie7, so the instructions are for ie8 or 9 in compatability mode):

go on an RTL 1.19 wiki (e.g., hewiki, arwiki or fawiki) as anonymous, using internet explorer 8 or 9. choose random article, then "edit". make sure your browser is in "compatability mode". note that there is no toolbar of any kind.


Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz34885.
Kipod created this task.Via LegacyMar 2 2012, 5:11 AM
TheDJ added a comment.Via ConduitMar 2 2012, 11:08 PM

should be checked with ?uselang=en to see if this is actually a rtl issue as well as verified with plain en.wikipedia.org and en.wikipedia with ?uselang=he, to see wether it is truly RTL interface mode of the RTL wiki's that are not compatible, or that either the toolbar is broken on all wiki's for IE7 or broken in just he.wikipedia etc.

SPQRobin added a comment.Via ConduitMar 2 2012, 11:18 PM

(In reply to comment #1)

should be checked with ?uselang=en to see if this is actually a rtl issue as
well as verified with plain en.wikipedia.org and en.wikipedia with ?uselang=he,
to see wether it is truly RTL interface mode of the RTL wiki's that are not
compatible, or that either the toolbar is broken on all wiki's for IE7 or
broken in just he.wikipedia etc.

It's indeed when the user language is RTL, not content language. So also e.g. enwiki with uselang=he

Kipod added a comment.Via ConduitMar 5 2012, 11:18 PM

(In reply to comment #2)

It's indeed when the user language is RTL, not content language. So also e.g.
enwiki with uselang=he

to make a long story short:
when

(mw.user.options.get('usebetatoolbar') == 1)
&&
(! $.wikiEditor.isSupported())

instead of falling back to old-style toolbar, no toolbar at all is shown.
since "usebetatoolbar" is the default, it basically means that all anon editors whose browser is not supported see this issue. registered editors can unselect the default "Enable enhanced editing toolbar" in their prefs, but anons can't.

it's a bit more of a problem with RTL simply because the minimum IE verion for the wikiEditor.isSupported() is IE-8 in RTL and IE-7 in LTR.

see jquery.wikiEditor.js for the list of minimum version supported for <s>all</s> most browsers.

peace.

RobLa-WMF added a comment.Via ConduitMar 6 2012, 7:09 PM

Trevor, could you look at this today?

TrevorParscal added a comment.Via ConduitMar 7 2012, 1:11 AM

Created attachment 10188
Removes static toolbar override

The problem is that the WikiEditor extension overrides the old toolbar statically by blanking the old toolbar config (done on the server in PHP) if the new toolbar is enabled. Of course, since the new toolbar has to not just be enabled, but also be compatible, this means there are some people who will get no toolbar at all.

If you apply this patch, we will only do toolbar replacement on the client, which means both toolbars will be built, and the new one (WikiEditor's) will win. In cases where WikiEditor does nothing because it's not compatible, the old toolbar will remain.

The downside is that the old toolbar will be visible briefly on load, and then disappear when WikiEditor is done building it's UI.

To solve THAT problem, you will have to have some way of the old toolbar knowing if it should disable itself. You could, for instance, add some code to it that says something like:

if ( $.wikiEditor && $.wikiEditor.isCompatible() ) {
  // don't initialize anything
}

This would go in resources/mediawiki.action/mediawiki.action.edit.js

The trouble is, if you do that, then you would have to know for sure that jquery.wikieditor is always loaded prior to mediawiki.action.edit (if it's going to be, we can't just use a dependency, cause that would mean it would AWLAYS be loaded, and we need it to be based on prefs and configs).

I'm open to ideas on how to sort this out better.

attachment DynamicToolbarOverride.patch ignored as obsolete

TrevorParscal added a comment.Via ConduitMar 7 2012, 1:13 AM

Also, note that was psudo code. It would need to use $.wikiEditor.isSupported() and probably return false, set a flag that it's disabled, etc.

TrevorParscal added a comment.Via ConduitMar 7 2012, 2:12 AM

Also note that after I played with it a bit, I was unable to reliable execute ANY code prior to mediawiki.action.edit - which means there's no way to solve this that I can see because the toolbar will always build out and then be later removed.

Kipod added a comment.Via ConduitMar 7 2012, 2:59 PM

is it possible to do it the same way it's done today (i.e., decision is made on server side based purely on user preferences), but add a small piece to, say, ext.wikiEditor.toolbar (or whatever is the right place) that looks today at $.wikiEditor.isSupported(), and add an "else" statement that will fire the old toolbar?

you don't necessarily need to teach wikiEditor toolbar about the old toolbar - it would brobably be enough to trigger, e.g.

$(document).trigger('wikiEditor_incompatible')

event, and elsewhere in the code trap this event and bind it to creation of old toolbar.

just an idea.

peace.

TrevorParscal added a comment.Via ConduitMar 7 2012, 6:40 PM

Created attachment 10191
Dynamically hide old toolbar

This was an attempt to fix this by adding an init module with position top which adds a CSS rule that will make the old toolbar hidden if the body has a class called "wikiEditor-enabled". It also has a script which decides if wikiEditor will be enabled based on compatibility.

This patch isn't quite complete, because the desired behavior is to detect if the toolbar module is going to be loaded and compatible, not wikiEditor in general. Nonetheless, it shows the problem, which is that mediawiki.action.edit is loaded and executed (the toolbar is built out) before the ext.wikiEditor.init module is executed, meaning the CSS rule not only isn't active because the class is added to the body too late, but the CSS rule isn't even added to the DOM yet.

I'm still open to ideas here.

attachment wikieditor-dynamically-hide-old-toolbar.patch ignored as obsolete

Kipod added a comment.Via ConduitMar 8 2012, 3:46 PM

one more try: did you consider migrating the "supported" logic to server side?

i have some limited experience with php, but did not look into mediawiki php code, so there might be some "coding guidelines" that forbid this which i am not aware of.
php provides you access to this information through
$_SERVER['HTTP_USER_AGENT']
with specific "browser", "version" and "minorversion" fields, which will allow you to execute the same "isSupported()" on server side.

just a thought.

peace.

TrevorParscal added a comment.Via ConduitMar 28 2012, 6:24 PM

Created attachment 10343
Dynamically hide old toolbar (fixed)

This patch fixes 2 bugs in the previous one

Attached: attachment.patch

bzimport added a comment.Via ConduitMar 28 2012, 9:40 PM

sumanah wrote:

I am told this patch is not quite working yet. Marking as patch, reviewed, till Trevor triumphs.

bzimport added a comment.Via ConduitApr 7 2012, 7:22 AM

sumanah wrote:

Robin, I don't know whether Trevor will have time to get back into working on this within the next few days -- can you take a look once you get back online? Thanks!

SPQRobin added a comment.Via ConduitApr 11 2012, 10:33 PM

(In reply to comment #13)

Robin, I don't know whether Trevor will have time to get back into working on
this within the next few days -- can you take a look once you get back online?

I'm not familiar with the code, so I can't really help, but I applied Trevor's patch and that fixes the bug as far as I tested.

RobLa-WMF added a comment.Via ConduitApr 11 2012, 10:57 PM

Trevor and I spoke about this problem. The attached patch solves the problem, but the cost is that it will cause a regression with bug 34431.

Trevor, Timo, and Roan had all gotten together and tried to solve this in non-evil ways (i.e. ways that don't make self-respecting programmers twitch). Being a non-self-respecting programmer, I started suggesting evil ways of solving this (PHP global config var, style="display:none" attribute on the old toolbar which then gets explicitly enabled in JS, etc), and that led Trevor to agree that there are probably some other evil-and-effective ways of solving this with just a little bit of work, so he's going to get the band together for the reunion tour. Sorry for mixing metaphors; I mean Trevor, Timo and Roan will make one more attempt at solving this.

Kipod added a comment.Via ConduitApr 12 2012, 1:59 PM

Thanks. this is fairly important, esp. because of micro$oft evil "compatibility mode". practically every day we get people[1] who activated this mode by mistake wondering where is their toolbar. anons do not even complain - maybe they don't even know something is missing.

reminder: "compat mode" throws IE 9 or 8 back to "IE7" mode.
on RTL wikis, the minimum "beta toolbar" support is IE8.
since beta toolbar is the default, this means that any unsuspecting soul who activated "compat mode" by mistake (the vast majority of them do not even know that such a mode exists, let alone that they are not aware they unwittingly activated it) without any toolbar whatsoever.


[1] and not only novices, either: i, personally, had had to help out of this ditch several very senior and veteran editors, with tens of thousands edits and > 5 years, including more than one sysop AND sysop emeritus.

TrevorParscal added a comment.Via ConduitApr 17 2012, 10:20 PM

A hacky fix for this has been submitted here: https://gerrit.wikimedia.org/r/#change,5209

This should be closed now pending review.

Catrope added a comment.Via ConduitApr 17 2012, 10:53 PM

(In reply to comment #17)

A hacky fix for this has been submitted here:
https://gerrit.wikimedia.org/r/#change,5209

This should be closed now pending review.

Merged, deployed, and working for me in production (IE8 in compat mode on hewiki).

Kipod added a comment.Via ConduitSep 5 2012, 9:04 PM

This issue came back with 1.19wmf20, so i am reopening this bug.

REPRODUCTION:

  • select an rtl wikipedia: (ar|fa|he).wikipedia.org
  • make sure your preferences on this wiki is the "Enable enhanced editing toolbar" (previously know as "beta toolbar") for editing. alternateively, log out: "Enhanced editing toolbar" is the default now.
  • browse selected wiki using IE 8 or 9
  • select "compatibility mode"
  • edit an article
  • note that there is no toolbar.

i do not have access to IE-7, but i suspect same thing happens there too.

using a registered account and un-selecting "enhanced editing toolbar" will bring back the "good old toolbar".

peace.

Kipod added a comment.Via ConduitSep 6 2012, 2:46 AM

mistake. this was an unrelated issue.

resetting to "RESOLVED".

Aklapper edited projects, added MW-1.19-release; removed MW-extension-1.19-version.Via WebDec 19 2014, 8:20 PM

Add Comment