Bug #20868

click-enlarge function for images does not work correctly in IE8

Added by Maik Matthias almost 10 years ago. Updated 9 months ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


The popup-window generated by the click-enlarge function produces an IE-Error stating that a function was blocked. This function is the submitted javascript-code for closing the popup window. This code is then destroyed by the IE, obviously to prevent XSS-Hacks.

Same problem with Typo3 4.1.10.

I think, it´s not a bug in IE8. Typo3 should not pass javascript-code via url parameters.

A workaround is to disable the "window.close"-function for the IE8-Browser via TS:

  1. IE8 Bugfix ClickEnlarge-function ###
    [browser = msie] && [useragent = Trident/4.0]
    plugin.tt_news.displaySingle.image.imageLinkWrap.wrap = |
    tt_content.image.20.1.imageLinkWrap.wrap = |

A better solution is to fix the core-file typo3/sysext/cms/tslib/showpic.php
There the window-close function could be implemented in the body-tag of the output html code for the popup:

<body bgcolor="white" onClick="window.close();">
(issue imported from #M11695)

0011695.diff View (5.06 KB) Administrator Admin, 2010-06-25 19:19

Related issues

Duplicated by TYPO3 Core - Bug #21539: openPic close popup internet explorer 8 incompatibility Closed 2009-11-12
Duplicates TYPO3 Core - Bug #21554: IE8 Cross Site Scripting Warning Closed 2009-11-15
Duplicates TYPO3 Core - Bug #22990: imageLinkWrap.JSwindow triggers XSS warning or Fails Closed 2010-06-24
Duplicated by TYPO3 Core - Bug #21919: XSS Error in IE8 when Picture is enlarged Closed 2010-01-06


#1 Updated by Maik Matthias almost 10 years ago

The reported bug affects the system extension tx_cms_showpic. Have anybody ever tried to click-enlarge an image with IE8? Nobody?
The alert displayed in the popup-window is (in german language): "Diese Seite wurde von Internet Explorer geändert, um das siteübergreifende Scripting zu verhindern".

#2 Updated by Simon Schick over 9 years ago

Hi, Maik

There are many posts (also TYPO3-forum-posts) which are talking about this problem ...


You can find the explanation in here:

You can find the reason of problem causes by the IE8-XSS-filter in the URL you're calling:

Here the IE8 can see that the whole content of this page is given by the GET-Param! here's the php-var $_GET['bodyTag']

<body style="margin:0; background:#fff;">&wrap=<a href="#" onclick="window.close();"> | </span>

And here you can see that there's some javascript given by the PHP-Var - and this is the XSS the IE8 won't like.

@Maik - if you know all these thinks - maybe other people need this explanation :)

One way to solve this problem could be to create a template so the js-code don't have to be given by the GET-params.
You can send the template-name by the GET-params so that this can be as configurable as it's now.
Another way (workaround) is to use the lightbox :D

#3 Updated by Thomas Ernst over 9 years ago


Modify file typo3/sysext/cms/tslib/ showpic.php

Modify function printContent() so that it looks as following

function printContent() {
header('X-XSS-Protection: 0'); // Disable CSS-Warning in IE8 (Typo3-Bug 11695)
echo $this->content;

#4 Updated by Maik Matthias over 9 years ago

Thanks Thomas (and Simon) for the workaround.
I solved the problem for me by another workaround long time ago (see on top).

But: This bug still exists on a lot of typo3-sites (including typo3.org!) and should be solved for all in the source-file "showpic.php".

BTW: It can´t be a serious fix to disable security checks. IMHO in this case IE8 is on the rigt way.

#5 Updated by Jörg Leshel about 9 years ago

Behaviour can get bypassed by disabling the crossite filter of IE8 for the website.

Configure server to send an additional http header -> .htaccess/httpd.conf

<IfModule mod_headers.c>
Header set X-XSS-Protection 0

#6 Updated by Maik Matthias about 9 years ago

Hi Jörg,

as I mentioned before: it can´t be a good advice to disable XSS protection. Doing it for the whole website or the server at all would be the worst decision.

Yet it´s better to workaround this topic by using some lightbox-extension instead. Your customers will appreciate that.

#7 Updated by Jörg Leshel about 9 years ago

Hi Maik,

you are right :) . just wanted to post another way to handle it, so people can decide by themselves.

#8 Updated by Nathan L almost 9 years ago

I made an attempt at fixing this one.

I added a new parameter to imageLinkWrap called windowTemplateKey

This allows you to define different templates in:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['tx_cms_showpic']['templateKeys']['KEYNAME'] = 'fileadmin/somefile.html'

I added a default/example template that isn't strictly necessary. These could be left out and left to the user to define.

myimg.imageLinkWrap = 1
myimg.imageLinkWrap {
enable = 1
width = 800m
height = 600m
JSwindow = 1
JSwindow.newWindow = 1
windowTemplateKey = KEYNAME

This generates a url like:


Then you can put whatever javascript you want in the "fileadmin/somefile.html"

#9 Updated by Nathan L almost 9 years ago

Another way to solve this would be to pass the template file name through the URL. This would eliminate the need for the complex "key" business.

Instead of "windowTemplateKey" I could add "windowTemplateFile" as a parameter. Then showpic.php would simply open up that file and use it.


#10 Updated by Nathan L almost 9 years ago

Another workaround, if my patch isn't a good idea. This workaround requires no modifications to Typo3 Core.

Create a new extension that defines tx_bettershowpic as an eID. This extension would look pretty much exactly like showpic.php, except it would allow you to configure different templates.

Then just set the JSwindow.altUrl = /index.php?eID=tx_bettershowpic

Unset the bodytag and stdwrap properties.

That's it. You have an image pop up that can contain Javascript, but where the javascript isn't passwed through the URL.

#11 Updated by Chris topher almost 9 years ago

Resolved as duplicate of #22990, which has been committed in rev. 8198.

#12 Updated by Benni Mack 9 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF