Topic on Extension talk:WYSIWYG/Archive 2

IE11 problems: with MW 1.22.0 + WYSIWYG extension (CKEditor): numbered and bulleted list empties document with save

If I use IE11 as browser when editing pages in environment described below, page will be empty after saving it. With Firefox, page can be saved without problems. I can not find any errors in logs of MW with IE11.

Has enybody else had this kind of setup and problem? ...any ideas how to get rid of this problem. If I remember right numbered and bulleted list worked with IE11 in MW 1.21.2.

My environment is like this:

• RedHat 6.3
• XAMPP for Linux 1.8.3-2

• PHP to 5.5.6
• MySQL to 5.6.14
• Apache to 2.4.7

• Mediawiki 1.22.0
• MW WYSIWYG 1.20.2 (MW WYSIWYG extension + manual modifications found from this site)
• Sphinx 2.1.3 (+ MW SphinxSearh extension)

In IE11, by pressing F12 DOM window opens. On "Emulation" -screen setting "Document mode" is set to "7 (default). If I change this to any value abowe 7 (8..10 or Edge), edited page with numbered and bulleted list can be saved succesfully. Only problem is that this setting does not stay in effect when page is re-edited and saved. Is it possible to change type of document for wysiwyg editor on server side somehow?

this in include/outputpage

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

set it at the beginning, after charset = utf8 for me its after $ret .= Html::element( 'title', null, $this->getHTMLTitle() ) . "\n"; around line 2260

Is it so that complete file name is this:

<mediawiki_install_dir>/includes/OutputPage.php

The row number is not valid for me, but I can find existing line:

$ret .= Html::element( 'title', null, $this->getHTMLTitle() ) . "\n";

so I added new line after prev. line

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

Is this correct place ?

In IE11, this seems to change document mode to "9 (Default)", just out of curiosity, what does this mean? With this fix, after quick test, editing with numbered / bulleted lists work with IE11, Chrome (Version 31.0.1650.63 m) and Firefox (26.0).

How sensitive this modification is to version number of browsers?

This setting should work fine, but it would be wiser to make the WYSIWYG extension change it (only when necessary: MediaWiki edit mode, WYSIWYG mode enabled) instead of having the webmaster struggling. Furthermore, be sure that the metatag is placed before every other metatag.

Good idea....

Wysiwyg editor is embedded in "original" wiki page which is also controlled by mediawiki. I guess this and also requirement to get it "first" was the reason why "194.156.246.226" adviced to put setting in file of mediawiki. Another issue is that in this location modification may be overwritten by future updates of mediawiki.

Perhaps better place for this kind of fix would be with a hook named "onBeforePageDisplay" used by wysiwyg. I added line "$out->addMeta( 'http:X-UA-Compatible', 'IE=9' );" in the end of code in "onBeforePageDisplay" which will produce line "<meta http-equiv="X-UA-Compatible" content="IE=9" />" on page....but it is located as last in the list of all "<meta.."'s.

Is there any other way to insert metatag http-equiv="X-UA-Compatible" to get it as first? ...or is there a way to sort "<meta" lines somehow at this point?

Related threads: corrupted_category, adding_metatag_as_first.

addMeta() should definitely support an optional argument to customize the tag's placement.

That would be good.

The original problem of this thread was that at start time of this thread, my IE11 used setting "IE=7" for MW 1.22 pages (because at that time wysiwyg treated normal mode of IE11 as "non compatible" with wysiwyg). I noticed that this caused blank page problem with list items of wikitext. Then to my question I got this advice to force IE11 to emulate mode "IE=9".

At some_point_later I found a way to enable wysiwyg also in normal mode if IE11 => I have now tested this again so that I removed setting of emulation mode "IE=9" from wysiwyg and then set up "Tools=>compatibility mode" ON with IE11 browser => it seems that blank page problem is back. If I then set "Tools=>compatibility mode" OFF, page will be in "Edge" mode with IE11, and page works just fine when there are list items included on page.

So the right solution to my original question was not to force emulation mode to "IE=9", but to switch OFF the setting "Tools=>Compatibility mode" of IE11 for wiki site (this will let browser to use the "latest" mode). I will leave this setting like this for my site, and report if it will not work properly.

=>(updated later:) Noticed some problems with focus on page with dialogs of wysiwyg in editing mode, see details below.

But if Compatibility Mode is switched on by default, it should be switched off by the extension.

Does that solve Existing category definitions will be corrupted... too?

Support for IE11 was disabled by Wikia, so I think there are some other flaws, aren't there?

I have not found any problems with MW 1.22 and IE11 normal mode, so I guess keeping IE11 in normal "Edge" mode is fine for MW1.22. (I do not know about Wikia, is it related to MediaWiki somehow?). With this normal mode setting (=no specific compatibility mode set in any places), numbered and bulleted lists worked fine in IE11.

But it seems that there are problems with IE11 normal mode and wysiwyg dialogs (in editing mode): focus on page is lost and moved into beginning of page at exit of dialog.

So...I have changed setting of my wiki now so that in includes/OutputPage.php there are no settings about compatibility mode (=>pages look better in normal mode of IE11), instead in hook "onBeforePageDisplay" compatibility mode is forced to IE=9 when wysiwyg editing mode is entered (addMeta() setting has effect dispite the position of "..IE=9.." as last meta directive).

So far this seem to work properly (=#6 source bundle >=17.02.14), also category and both list items (numbered and bulleted) work without problems.

thanks Riparap you idea about:

s it so that complete file name is this:

<mediawiki_install_dir>/includes/OutputPage.php

The row number is not valid for me, but I can find existing line:

$ret .= Html::element( 'title', null, $this->getHTMLTitle() ) . "\n";

so I added new line after prev. line

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

worked for me, thanks a lot