Closed Bug 235877 Opened 20 years ago Closed 14 years ago

Iframe elements in XUL (like 'page' etc.) can not be made transparent

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 532569

People

(Reporter: alfredkayser, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
Summary: 'page' elements in XUL can not be made transparent. → Iframes elements in XUL (like 'page' etc.) can not be made 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...
Summary: Iframes elements in XUL (like 'page' etc.) can not be made transparent → Iframe elements in XUL (like 'page' etc.) can not be made transparent
Blocks: 276704
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'.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Flags: blocking1.9?
The patch currently being considered for 1.9 in bug 177805 should fix this.
Depends on: pixels
Flags: blocking1.9? → blocking1.9-
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
Assignee: hyatt → nobody
Is this perhaps now a dupe of bug 532569?
Yes
Status: REOPENED → RESOLVED
Closed: 17 years ago14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.