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.

(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

(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.

Trevor, could you look at this today?

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

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.

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.

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.

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

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.

Created attachment 10343
Dynamically hide old toolbar (fixed)

This patch fixes 2 bugs in the previous one

Attached:

sumanah wrote:

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

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!

(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.

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.

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.

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

This should be closed now pending review.

(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).

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.

mistake. this was an unrelated issue.

resetting to "RESOLVED".