Topic on Extension talk:CodeEditor

How can a user disable this if it's installed as an extension (rather than as a gadget)? I found nothing in the preferences on enwiki, and the extension's page only mentions a server-side variable ($wgCodeEditorEnableCore).

There is a toolbar option that disables the editor (remembered by cookie). There is no preference option (and I doubt we will add it).

Thanks. And why not a preference option?

Because in general we want to have fewer preference options, especially when it comes to preferences that are used by a very small set of users.

... and that cookie has recently been reset (or expired?) and now the editor is enabled once again as my default. "Turning it off" again would require me toggling the button in WikiEditor - as I've done many times before when this has happened - but I never get the "chance" to hit that button because it just hangs & hangs (IE8/XP Pro, Wikipedia/Wikisource/etc. same story everywhere) whenever I open an applicable page (User: js css, MediaWiki: js css - doesn't matter).

Usually I can use the built-in IE "debugger" to isolate sh!t like this and more often than not it's WikiEditor and it's screwy "button & icon generated from over here, button & icon generated from over there, buttons & icons generated from any & everywhere" design, but this is different & can't run it without the "hang" preventing it from reaching anything meaningful in the console (and don't get me started on spirited span vs. old-school image - I wish somebody would fish or cut bait and standardize one or the other already.... but I digress).

So what's the way to turn the cookie off again so that reads as my default given the absence of some similar option in User: preferences? Another adventure in API again where am not an admin screws me either way? TIA. --

I'm considering starting to use localStorage to safe some of this, which would be a tad more permanent and not submit it with each and every request. It will be a while before that is done though. I'll attempt to run it in IE8 myself. See if I can find an IE8 specific problem.

Be aware of bugzilla:64721 (mw.loader.store should not occupy all of localStorage for itself).

This post was posted by He7d3r, but signed as Helder.wiki.

The impermanence of the preference setting is quite inconvenient indeed, and it general it makes no sense to use a temporary measure for a setting that's meant to be permanent. Since this is an extension and not part of core mediawiki, I really don't see why including a preference would be such a problem...

Perhaps we should have hidden preferences and allow the CodeEditor UI to switch those using JS...

That makes no sense as well and is contrary to normal best practices (to the best of my knowledge) on any wiki project. Your earlier assertion about this being "... preferences that are used by a very small set of users" seems hard to prove through cookie usage alone - if it ever was a formal preference, what was the opt-in/opt-out percentages?

Debate aside - this is no longer an isolated low-level issue for me since the remaining project where I'm an admin has also reset itself and CodeEditor is now "on" no matter what I try to avoid it. I can no longer edit in any namespace where CodeEditor is present without edit-mode hanging the session. I cannot "reach" the code-editor button before the focus is lost to the hang.

Happens when logged in or logged out now. Relevant? Pref settings

• Show edit toolbar OFF
• Enable enhanced editing toolbar ON
• Enable wizards for inserting links, tables as well as the search and replace function OFF

All the latest patches for IE8 & XPpro applied. Some sort of relief is desperately needed here. TIA. --

Interesting....

Even when I disable all 3 preferences [above] concerning toolbars altogether - giving me no toolbar whatsoever in most namespaces upon edit mode - CodeEditor still manages to give me the finger, activate WikiEditor, turns itself on and proceedes to hang like it was before the preference change(s) in those namespaces its been "cleared" for (MediaWiki, Module).

Anyone able to replicate?

I'm sorry. This is beyond unacceptable. If a User: opts for no toolbar (no old toolbar, no WikiEditor, no enhanced WikiEditor), the equivalent of disabling all 3 previously mentioned User Preferences, then that is what Users should get. CodeEditor should not usurp that basic standard. --

You can submit patches like anyone !

I would if I could... "fixing" something like the above is beyond my limited skill set. Sorry.

I see similar complaints have already been submitted as Bugzillas however; bug 45850, bug 46779 and bug 62250 in particular. --

Thanks for the pointers. I left a comment on bug 46779 with a link back to this discussion.

I invested some time to bring all of this together. Will take a while before it's all passed review I think, but I think it works quite nice and intuitive with the patch that I created.

fwiw... these are my findings @ test2.wikipedia.org under 1.24wmf4 & IE 8. From the chicken bones I can read at Git, it seems more than one "patch" was applied / still needs to be applied but don't hold me to that

Settings Key

• User pref "show edit toolbar" = Option 1
• User pref "use enhanced toolbar" = Option 2
• User pref "use wizards and tables..." = Option 3

With all three Options disabled, the previous issue of CodeEditor forcing WikiEditor "on" no longer seems to be an issue. No toolbar, neither old or new, rendered at all so CodeEditor not "present" no. I'd say this is Fixed.

With only Option 1 enabled, the old toolbar appears in all namespaces BUT in those dealing with MediaWiki and Modules. No toolbar of any sort appears in those cases. I'm not sure if this is normal or not (boy do I miss meatspace) and can't recall if I tested for this earlier if ever. Personally don't really care because I never plan to enable the "old" toolbar either way but other folks might take issue with this nevertheless.

From here on, there is no difference between an enabled Option 1 or a disabled Option 1 as long as Option 2 was always enabled at the same. This has always been the normal and intended behavior concerning Option 2 to the best of my knowledge --> An enabled WikiEditor (enabled Option 2) always superseded the old toolbar (enabled Option 1).

That said, all other combination of Options 1, 2 & 3 no longer produce the previous "hangs before I can toggle off" issue & CodeEditor is easily toggled on & off here (plus it stays that way over session logins/logouts).

In fact, most other "minor" layout &/or rendering &/or focus issues that drove me to avoid CodeEditor altogether in the first place seem to be gone now too ( damn that last comma?). I'd have to see the same under a full wmf4 deployment to futz with it again - it could just be the watered-down beta site & settings.

Anyway, hope that helped.

One last suggestion - I see there is some "new" feature(s) at the bottom left of the EditBox with a "stop" symbol, a "yield" symbol and an italic letter i. Would be useful to add some pop-up descriptions for each upon a typical mouseover. Where would I find more info on whatever that is. TIA.

I noticed that part of the problem here is that apparently CodeEditor was working, and now seems to be totally broken icw IE7/8. This is unintentional, and I suspect it happened after the last update. Can you check if you get similar freezes on http://ajaxorg.github.io/ace-builds/kitchen-sink.html ? Then we can at least update to a newer version that IS working with IE7/8. Opened bugzilla:64559

Not exactly sure what it is that I'm suppose to be looking for at that URL, but if it is the same "forever hang" as I was getting on the wiki-sites; nope- no hang there. able to scroll. able to select/deselect on the left... in short, "focus" not an issue and I am able to do pretty much everything I tried.

The following appears upon landing on that page if it helps any...

function foo(items, nada) {
    for (var i=0; i<items.length; i++) {
        alert(items[i] + "juhu\n");
    }	// Real Tab.
}

Sorry if I came off like the typical wiki-jerk earlier & Thanks again for any attention given to this matter - I realize the death clock is ticking for those versions of IE and addressing issues for them is an investment producing less & less in the way of positive returns as the final hour draws near. At the same time, that's what I'm stuck with for work reasons and really wouldn't be able to "contribute daily" otherwise. Prost.

I too apologize, I should know better. Thank you for confirming that the above link does load for you, this indicates that indeed there was a serious regression in our last CodeEditor update with regard to IE7/8, that had gone unnoticed.