TYPO3 Core

Don't we have somebody with a good contact to the Sencha guys, such that we get this version quickly?

Stanislas, you might want to bring this to everybody's attention on the Core list?

At the moment, the only workaround I can see is to force IE 11+ to behave like IE 10 by use of meta tag

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

In TYPO3 6.2, this meta tag is already added in the backend.

In the frontend, the meta tag would need to be added whenever the ExtJs libs are added on the page and the client is IE 11+. Not sure how to do this when there is non-cached content on the page.

Note: this meta tag needs to be added very early for IE to take it into account, probably before any css and js. So additionalHeaderData cannot be used for this tag.

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27758

Stefans solution doesn't work e.g. if the RTE is loaded dynamically in the iFrame.

What is the status of the ExtJS update anyway?

After some Slack communication with Mathias Schreiber and Alexander Stehlik:

Since it's improbable that TYPO3 will "buy" ExtJS 3.4.2 (which ships IE 11 detection), it makes sense to patch ExtJS. ExtJS is compressed with the YUI Compressor. Every ExtJS file comes in two variants in typo3/contrib/extjs, the compressed file and the uncompressed file suffixed with "-debug".

The IE 11 detection needs to be built in to all files containing it. There is a StackOverflow article with the solution.

This can be tested as follows:

• Login to TYPO3 with IE11.
• Open the console (F12).
• Go to the Emulation tab and set Document mode to "Edge (Standard)".
• Go to the console.

Enter the following commands (of course without : false or : true at the end) - the detection doesn't work correctly:

• Ext.isIE: false
• Ext.isGecko: true
• Ext.isIE10p: false

After applying the patch, reload and test again:

• Ext.isIE: true
• Ext.isIE11: true
• Ext.isGecko: false
• Ext.isIE10p: true

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37791

@Lorenz Ulrich on https://review.typo3.org/#/c/37766/, you said about generating minimized files:

I used the yuicompressor from the OS online service http://refresh-sf.com/

However if I try to reproduce that by pasting typo3/contrib/extjs/adapter/ext/ext-base-debug.js content into that service I get a very different result than you. The most obvious difference being that ext-base-debug.js clearly mentions version '3.3.1', whereas ext-base.js clearly mentions version "3.4.1.1". How would explain the difference ? Why are versions different ? How exactly did you generate those files ?

I am asking that because it seems that this patch introduced a bug where backend breaks completely in production mode, but not in debug mode.

@ Adrien: What I did

• I opened ext-*-debug.js from master (7.x-dev at this time) and added IE11 support.
• Then I pasted the code to refresh-sf.com and used the YUI compressor to compress ext-*.js.
• I did not take care of the backporting because I didn't merge the patch myself.

I don't have access to the commit that was done for 4.5. I suspect that the ExtJS version auf 4.5 and 6.2+ are different and the person who did the backport accidentially copied the files instead of building new versions.

Update: I just could take a look at the commit for 4.5 and it clearly seems to be the case that the production files were not rebuilt based on the ExtJS 3.1 versions but just copied from the versions for 6.2+. I don't know the workflow for contributing to 4.5, but it should be easily fixable (and must be fixed).

4.5 has reached its end. There won't be updates anymore (unless for ELTS-users), sorry.

This is about ELTS users. They got 4.5.41 with a patch that can break the backend.