[wp-trac] [WordPress Trac] #42503: Internet Explorer 11 not compatible with Wordpress 4.8.3 (TinyMCE editor)

[WordPress Trac]

#42503: Internet Explorer 11 not compatible with Wordpress 4.8.3 (TinyMCE editor)
--------------------------+------------------------------
 Reporter:  chrossat      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  TinyMCE       |     Version:  4.8.3
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by 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?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42503#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform