Bug #20868
closed
click-enlarge function for images does not work correctly in IE8
0%
Description
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:
- IE8 Bugfix ClickEnlarge-function ###
[browser = msie] && [useragent = Trident/4.0]
plugin.tt_news.displaySingle.image.imageLinkWrap.wrap = |
tt_content.image.20.1.imageLinkWrap.wrap = |
[end]
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)
Files
Updated by Maik Matthias over 14 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".
Updated by Simon Schick over 14 years ago
Hi, Maik
There are many posts (also TYPO3-forum-posts) which are talking about this problem ...
f.e.
http://www.typo3.net/forum/list/list_post//92371/
http://www.nabble.com/IE8-clickenlarge-problems-td23562686.html
You can find the explanation in here:
http://blogs.msdn.com/ie/archive/2008/07/01/ie8-security-part-iv-the-xss-filter.aspx
You can find the reason of problem causes by the IE8-XSS-filter in the URL you're calling:
http://YOUR_PAGE/index.php?eID=tx_cms_showpic&file=uploads%2Fpics%2Fmypic.jpg&width=800m&height=600m&bodyTag=%3Cbody%20style%3D%22margin%3A0%3B%20background%3A%23fff%3B%22%3E&wrap=%3Ca%20href%3D%22%23%22%20onclick%3D%22window.close%28%29%3B%22%3E%20%7C%20%3C%2Fspan%3E&md5=ae1a959ecd61104ccfbece969e08fc21#
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 no-lastname-given - 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
Updated by Thomas Ernst over 14 years ago
Workaround:
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;
}
Updated by Maik Matthias over 14 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.
Updated by Jörg Leshel almost 14 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
</IfModule>
Updated by Maik Matthias almost 14 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.
Updated by Jörg Leshel almost 14 years ago
Hi Maik,
you are right :) . just wanted to post another way to handle it, so people can decide by themselves.
Updated by Nathan L almost 14 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"
Updated by Nathan L almost 14 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.
Thoughts?
Updated by Nathan L almost 14 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.
Updated by Chris topher almost 14 years ago
Resolved as duplicate of #22990, which has been committed in rev. 8198.
Updated by 
