In for example the Tools/Options dialog, the different pages of the configuration panels can not be made transparent. I wanted to make one background image for the whole of the dialog, but the 'page' XUL element refuses to be transparent. If I set the background style to 'transparent none', it should not paint its background at all, but currently it paints it completely white, except when background-color or -image is set, then the corresponding color or image is used. It has probably to do with the following code: http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSRendering.cpp nsCSSRendering::PaintBackground falling back to 'default background color' in some cases. However, in the case of Tools/Options the 'page' element is not 'root' or something like it, and support 'transparent' (ie do not draw the) background, if the background is transparent.

The attached testcase should show a green background all over and some text inside the contained iframe - and it does, if the file is opened in a browser window. If you open the file as a chrome window (eg. by |seamonkey -chrome testcase.xul| at the commandline or by |open("file:///testcase.xul", "", "chrome"| from the JSC), however, the iframe isn't transparent anymore. Its background-color is white (or any other colour your native theming provides for window backgrounds), even though DOMI says it's set to transparent...

In current build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081205 Minefield/3.0a8pre) this is no longer an issue, so we can now mark this is as 'FIXED'.

Do you have a bug number? Else the correct solution would be WFM...

It used to be a problem and it is fixed by a number of bugs surrounding Cairo and transparent frames, so it unclear precisely which bug fixed this.

Actually it not fixed, I tested it wrongly. It seems to work when you test the attachment in the browser, but if you test it as real XUL (using -chrome) then the problem is still there.

i am seeing this too. it causes trouble in an extension i am currently writing where this is essential. tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090105 Minefield/3.0a8pre

The patch currently being considered for 1.9 in bug 177805 should fix this.

Sorry, I meant 130078.

Is this perhaps now a dupe of bug 532569?

Yes