Topic on Extension talk:WYSIWYG

IE11 problems:

Creating first initial category definition works on page where there are no categories before. After editing page with IE11 where there already is category defined, category definition will be corrupted after page has been saved.

It will be also corrupted if button "code" is pressed (to toggle between wikitext and wysiwyg view). I quess this is same kind of issue as in post by "Hoggle42 (talk)‎19:20, 20 November 2013" "Editor_removes_assigned_category_16286" (but I do not know if this is caused by the same reason as with IE9 explained by Hoggle42).

This is some kind of parsing error, because when i press button "Code", definition of category will be [[Category: |Testi]] as wikitext (there is extra "|" character added).

This problem did not occur with Chrome (32.0.1700.102 m) or Firefox (v26.0), it appeared in IE11 only.

I was able to go around this problem by commenting out following lines in ckeditor/plugins/mediawiki/plugin.js, but I quess this will make wysiwyg editor incompatible with older versions of IE:

        /*16.12.13 ->*To make category work with IE11***
        if (CKEDITOR.env.ie)
            text = htmlNode.text;
        else
        *16.12.13 <-*/ 
            text = htmlNode.textContent;

Is there a way to find out what is the exact version of browser (not just IE, or FireFox)?

Any better ideas how we can get rid of extra "|" character with IE11?

Browser sniffing is bad practice. Instead, try replacing the above block with the following:

if (typeof htmlNode.textContent != 'undefined') text = htmlNode.textContent;
else text = htmlNode.text;

textContent should be correctly supported in IE11 and other up-to-date browsers, while IE<11 could still use the fallback property.

This looks much better and works ok in my installation (with IE11, FireFox (v26.0/ v27.0). Thank you very much.

Glad to help ;-)

Have you tested the change with older versions of IE, and maybe with other browsers as well? If it is working fine for them all, then I could send a patch to Gerrit.

I tried my installation (#6) only with IE8, but it does not work for some reason: page with bulleted or numbered list will become empty when mode is changed from wysiwyg to wikieditor. If list is created in wikitext mode and then switched to wysiwyg it works. I tried to cancel this modification, but it did not help, result was the same with IE8. I think it must be some other kind of problem but I could not find where the problem is :( .

This extension is very buggy, and every bugfix appears to uncover new problems :(

I'm seriously thinking of closing the documentation page and directing users to VisualEditor (perhaps buggier than WYSIWYG, but newer).

Problem was caused by this IE8 problem, for some reason with IE8 there where extra attribute "data-cke-expando=" left in code when editing mode was switched to wikitext. I had not applied that fix in my installation earlier. Your modified test seems to work with IE 8 without problems as does my #6 installation too.

To be clear, no problems in IE8 nor IE11?

AFAIK, IE has a feature to see webpages as if they were viewed using a previous version (IE10, IE9). Such tests would be useful (if you can), although I actually don't care much of supporting legacy browsers.

I have tested this fix (and #6 bundle) with IE8, IE11, FireFox (v26.0, v27.0) and Chrome(32.0.1700.102 m): with these browsers wysiwyg of #6 bundle works ok (with the modification you suggested).

With IE11 I have not noticed before that I have on page "Tools=>Compatibility View settings" selected option "Display intranet sites in compatibility view". With this setting on (#6 bundle of) wysiwyg works ok. If I deselect that setting, wysiwyg eiditor won't start and it reverts to wikieditor.

We could consider developing some fixes/updates to make it working on the real IE11. According to , support for IE11 has been disabled deliberately. Can you try to reenable it somehow and report any errors? Thanks in advance.

I had to add following code in function CKEditor_IsCompatibleBrowser() of file ckeditor/ckeditor_php5.php (placed before last return false; -line) to make wysiwyg start in normal mode of IE11. Based on quick test, #6 bundle seems to work with normal mode of IE11 too. I am not expert on this field so it may be that rule to test version of IE11 is not perfect, but as it is last test of block it should not harm other tests in any way (+ there is always possibility to switch into compatibility mode if wysiwyg does not work in native mode of IE11 for some reason).

else if ( strpos($sAgent, 'like Gecko') !== false &&  strpos($sAgent, 'Trident/7.0; rv:') !== false  )
{
        /*IE11 in normal mode:
          Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
        */
        $fVersion = (float)substr($sAgent, strpos($sAgent, 'rv:') + 3, 4) ;

        return ($fVersion >= 10.0) ;
}

I do not have possibility to test this with IE9 or IE10 browsers.

Inserting

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE10">

as the first metatag in the page (I don't know how to do this in MediaWiki, sorry) should force IE11 to Compatibility Mode.

Maybe the devs at Wikia/WYSIWYG weren't aware of this workaround. If we succeed inserting the metatag on "wgAction=edit" only, we'll solve many problems at once.

I think I have already done this kind of modification because of this empty_page problem. Definition is currently in file <mediawiki_install_dir>/includes/OutputPage.php like this (NOTE! File is not included in #6 bundle):

$ret .= Html::element( 'meta', array( 'http-equiv' => 'X-UA-Compatible' ,'content' => 'IE=9' ) ) . "\n";

Modified setting helped to solve the empty page problem with bulleted and numbered lists on save with IE11 browser earlier. I do not remember why setting "IE=9" was selected, because any one of the values 8, 9, 10 or Edge would have done the trick in that case.

So WYSIWYG should already be enforcing the Compatibility Mode: to ensure that, you should reset your browser's Compatibility settings and check that IE is defaulting to Compatibility Mode.

Moreover, could that setting be edited by the extension itself (e.g. with a hook)?

Good idea ... I just do not have skills to do this (see also thread: numbered_and_bulleted_list_empties_page_with_save.