Last modified: 2012-02-22 12:35:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2074 - PNG transparency fixes for IE users
PNG transparency fixes for IE users
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
PC All
: Lowest enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 6765 7332 (view as bug list)
Depends on: 18470
Blocks: 640
  Show dependency treegraph
Reported: 2005-05-05 11:13 UTC by Zhen Lin
Modified: 2012-02-22 12:35 UTC (History)
5 users (show)

See Also:
Web browser: Internet Explorer
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Proposed patch (1.89 KB, patch)
2005-05-05 11:18 UTC, Zhen Lin

Description Zhen Lin 2005-05-05 11:13:20 UTC
Using the DirectX filter workaround
(DXImageTransform.Microsoft.AlphaImageLoader), IE users are able to see PNG
images with transparency as they are supposed to be.

This is already implemented partially for the wiki.png logo.
Comment 1 Zhen Lin 2005-05-05 11:18:12 UTC
Created attachment 500 [details]
Proposed patch

Most of the code was originally adapted from IEFixes.js by Chris Fritz

1. wikibits.js writes an IE conditional comment into the document body. (This
is so that all skins are affected by the fix, not just Monobook or Standard,
2. IEPNGFix.js hooks fiximages() to the onreadystatechange event.
3. fiximages() invokes fiximage() on each image element.
4. fiximage() converts the image to use the DirectX filter.

blankSrc in IEPNGFix.js is set to "/w/skins/common/images/blank.gif". This
image must exist and should be a 1x1 transparent GIF.
Comment 2 David Benbennick 2005-06-28 18:57:33 UTC
I had to give up on [[Template:Chess position t]] because of this IE 
bug.  You say "This is already implemented partially for the 
wiki.png logo."  So is it possible to produce transparent PNGs that 
work on IE (without this patch having been applied)?  How?
Comment 3 Zhen Lin 2005-06-29 07:49:46 UTC
The patch extends the technique used to make the logo PNG transparent.
Comment 4 David Benbennick 2005-06-29 15:14:35 UTC
[[:Image:Wiki.png]] apparently does not have transparency working in 
IE6, as can be seen on the 25 pixel thumbnail of the logo at 
[[Template talk:Chess position t]].  Perhaps you are referring to 
some other image?  I'm still curious about this technique that makes 
transparent PNGs work with Internet Explorer.
Comment 5 Zhen Lin 2005-06-30 07:09:21 UTC
That is not what I meant. I specifically meant the logo in the top-left of the
Monobook layout.

The technique itself is fairly well known - using the DirectX compositor to
render on top of a transparent GIF. The patch adds some JavaScript code to do
this for all PNG images (or more accurately, IMGs) anywhere on the page. It can
be adapted for use in a customised Monobook.js, but it may not be as effective
as applying the patch.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-15 02:37:44 UTC
*** Bug 7332 has been marked as a duplicate of this bug. ***
Comment 7 Erwin Dokter 2008-11-27 15:35:07 UTC
IE6 will handle 256 color PNG transparency OK (so the chess template should work OK), but not higher-color ones. Also note that DXImageTransform.Microsoft.AlphaImageLoader does not handle borders very well. For that reason, some javascript is needed. For reference, see [[en:MediaWiki:Common.js/IE60Fixes.js]]. I don't think this can be built into MediaWiki as is...
Comment 8 Erwin Dokter 2009-04-16 10:22:02 UTC
Marked as Fixed; implemeted in [[en:MediaWiki:Common.js/IE60Fixes.js]].
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-04-17 11:27:32 UTC
MediaWiki is not just used on the English Wikipedia.  It's used on every other Wikipedia and probably tens of thousands or more of other wikis.  Do not mark bugs as fixed unless a fix has been committed to the MediaWiki software, to be deployed to *all* wikis that use it.
Comment 10 Erwin Dokter 2009-04-17 13:32:41 UTC
This bug has been open for four years and has never been assigned. It is highly unlikely that a *native* solution will ever be implemented, considering the age of IE6. Other projects that want transparency can simply copy the javascript from the English Wikipedia.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-04-17 13:40:53 UTC
If it's concluded that native IE6 PNG transparency support will not be implemented in MediaWiki, which would be reasonable, the bug could be closed WONTFIX.  I wouldn't object to that, given its obsolescence (and they tend to have performance issues AFAIK), but I'd like to hear from a couple other developers before WONTFIXing.
Comment 12 Kai Liu 2009-04-17 13:42:51 UTC
As much as I would love to see IE 6 die, the reality is that the uptake of newer browsers has been very slow, and even after all these years, IE 6 still has a significant market share (depending on what website's stats you look at, even larger than Firefox's).  This is especially true in corporate environments where IT managers are generally very conservative about software updates and in certain geographic regions such as China (where Firefox has struggled and where high piracy rates coupled with popular locally-brewed browsers like Maxthon have severely hampered the uptake of IE 7 and 8).  Since any IE-specific fix can be easily and reliably blocked out with a "conditional comment", it does not add any undue burden to MediaWiki to include an IE-specific fix.
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-04-17 13:45:00 UTC
Aren't there noticeable performance implications to trying to apply this filter to all the PNGs on the page?
Comment 14 Erwin Dokter 2009-04-17 22:04:22 UTC
Yes, there is a performance impact, but it is only noticable when the number of images on a page reaches the hundred.
Comment 15 Siebrand Mazeland 2009-06-04 11:02:01 UTC
Update Web browser.
Comment 16 Siebrand Mazeland 2009-06-04 11:35:33 UTC
Adding testme. Please test with Internet Explorer 8 and note the result here.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-06-04 17:22:24 UTC
(In reply to comment #16)
> Adding testme. Please test with Internet Explorer 8 and note the result here.

See bug 234 comment 15.
Comment 18 Erwin Dokter 2010-09-04 14:36:05 UTC
Recommend this bug be closed as WONTFIX. It is apparrent there will be no native solution available.
Comment 19 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-09-05 17:26:22 UTC
I don't think this is high-priority, but at this point I don't think it's WONTFIX either.  If someone wants to write and test a patch for this, I'd be okay with seeing it committed.  Once IE6 really has such negligible market share that we're not interested in even accepting a patch is when we should mark this WONTFIX.
Comment 20 Erwin Dokter 2010-09-26 21:42:43 UTC
Fact is, there is no way to fix this server-side, short of converting the image to another format. That leaves client-side javascript, which has it's minor shortcomings, such as handling borders.
Comment 21 DieBuche 2010-12-05 14:50:12 UTC
*** Bug 6765 has been marked as a duplicate of this bug. ***
Comment 22 DieBuche 2010-12-05 14:56:38 UTC
Here's another script for handling this via a htc:

One thing that might prevent us from applying it to all pngs though:
"Due to an IE bug, if you are putting links within an element with a transparent background, the element must not have a CSS relative/absolute position. Otherwise the links will likely be un-clickable."
Comment 23 Erwin Dokter 2010-12-18 00:55:52 UTC
That basically uses the same technique (the DXTransform filter) as the current javascript on en: does, so it bumps into the same limitations. The en: script handles borders through the use of extra divs, which is not elegant.
Comment 24 Erwin Dokter 2010-12-18 01:11:05 UTC
Current market share of IE6 as of November 2010 is... 4.1% and dropping fast.

I am closing this bug. It is obvious a native solution is too complicated due to the filter's limitations; It would have to serve a different HTML structure to IE6 to circumvent these limitation just to handle PNGs, as is apparent with the javascript in use on This is not worth the effort to build a server-side solution into MediaWiki.

Note You need to log in before you can comment on or make changes to this bug.