Internet Explorer 11 not compatible with Wordpress 4.8.3 (TinyMCE editor)

[chrossat]

Hello,

I am a webdesigner and have noticed that there is a compatibility problem in the administration of Wordpress sites version 4.8.3 with Internet Explorer 11, a problem that does not appear with version 4.7.7 for example. The problem is the following.
I use the TinyMCE editor. Visual mode does not work. Once the sitebuilder is open, in visual mode, the content of the page to be modified is empty and the editor icons (bold, format, etc.) are not present. Only the text mode (HTML) works.

Are you aware of this problem?

With my greetings

3. Rossat

Mediasynergie
info@…
c.rossat@…
+41 79 414 99 86

[ndavison]

Hi there,

I can confirm the same issue. However, It may not be affecting all IE 11 environments, possibly just those whose user agent is in IE7 mode. I believe the following commit introduced the "issue":

​https://github.com/WordPress/WordPress/commit/dd0d1105203f57d626409d853ce01c22f432cccd#diff-eb309e818a52f04ab37b79edcba3f7ef

Line 2992 in general-template.php is the culprit. Basically it's disabling the rich editor for IE user agents containing the string "MSIE". For more on IE 11 user agents see:

​https://blogs.msdn.microsoft.com/ieinternals/2013/09/21/internet-explorer-11s-many-user-agent-strings/

Under the "Compatibility View" heading you'll see what happens to the user agent when IE 11 goes into compatibility mode - note it contains "MSIE". Also note that, in the Intranet Zone, IE 11 defaults to compatibility mode. I'm not sure about anyone else, but my experience with IE use inside of Intranet environments typically involves one area of an IT department leaving this as default (to accommodate legacy web app usage perhaps), and another area (those responsible for websites) using the X-UA-Compatible HTTP header or HTML meta tag to override this default on a site by site basis. So this issue will probably affect you if:

• You are using Wordpress in an Intranet environment.
• Your users have access to IE 11.
• Your IT department has IE 11 set to default for the Intranet Zone.

Whether you use X-UA-Compatible or not to reset IE 11 back into Edge mode doesn't factor into this issue I don't believe, since that won't influence the user agent value (i.e. the header is set in the response, while the user agent is in the request).

As the MSDN blog post mentions, the best approach is to feature detect in Javascript. Given this is about a JS library not loading (TinyMCE), perhaps the best solution is to feature detect vs user agent string detect?

Possible work around: beg your IT department to not default to IE7 mode in the Intranet Zone?

[azaozz]

Hi @chrossat and @ndavison, as far as I see that check should be something like:

strpos( $_SERVER['HTTP_USER_AGENT'], 'Trident/7.0;' ) !== false

to test for IE11 (standard) and IE11 (compatibility mode).

Seems TinyMCE works properly when IE11 is in compatibility mode too.

[azaozz]

In 42503.patch: change the test in user_can_richedit() to also detect when IE11 is in compatibility mode.

[Clorith]

Patch looks good on IE11, runs rich edit in both modes as expected.

[azaozz]

In 42529:

Editor: change the test in user_can_richedit() to also detect when IE11 is in compatibility mode.

Props ndavison, azaozz.
Fixes #42503 for trunk.

[azaozz]

Reopen for 4.9.3 consideration.

[SergeyBiryukov]

In 42551:

Editor: change the test in user_can_richedit() to also detect when IE11 is in compatibility mode.

Props ndavison, azaozz.
Merges [42529] to the 4.9 branch.
Fixes #42503.