Please consider porting the fix for bug 264708 to HTML, or generalising it. HTML suffers from the same problems as bug 264712 and bug 265711. - N.

test case.

Oops, typo - sorry. That's bug 264712 and bug 264711. - N.

Just imagine what will happen if you are reading news in your browser and then in other tab you open HTML which have ability to hide the chrome. You will loose all your user interface and will have no control over what this HTML page is doing. Allowing such an extension to HTML will be very stupid from security standpoint. On the other hand nothing can stop you to create XUL that hides it's chrome and embeds content of wanted HTML page in <iframe>. I tried it and it did not worked for me. But I have only 30 min knowledge of XUL :) If I understand it right then it should be possible to create something similar as Windows Web Content on Desktop. They could be even semi-transparent on Win2k and newer.

Dainis, Your concern is good, but security and rendering are completely separate issues. You will never be able to destroy security with the tab scenario you describe - not now, and not if more transparency support is in place. Security comes first. Normal HTML pages can't use the "chrome" feature string in window.open(), so they can _never_ create a window that is "pure" HTML. They can only create windows that are HTML-inside-XUL. You can get around security if you digitally sign normal HTML content. In that case, the website is trusted and all features provided by Mozilla should then work. The splash screen of the Mozilla Application Suite is an example. Today, the titlebar is a problem for trusted HTML windows because your code fix only extends to XUL. So with normal security in place, transparency/titlebars are not a problem for HTML. With full trust (no security) in place, transparency should work for HTML. So I think the part of your code that makes the titlebar disappear properly is really needed for the secure HTML case. The other part of your code, which supports 1-bit transparency is needed just for all platform support. Please consider applying the fix to HTML. - N.

WONTFIX should only be set by module owner, peer, or QA.

I don't understand what needs to be done here. We simply don't support toplevel HTML windows.

I don't understand what needs to be done here. We simply don't support toplevel HTML windows.

roc, are you saying the test case shouldn't be attempted? I merely observe that the XUL bugs also occur if this test case is run. Granted, toplevel HTML makes little sense for a browser, but what about for app developers? A UA stripped of all navigational chrome is a useful idea, especially when combined with transparency. Separate to that, is it sane to apply a quality fix to obvious other cases before everyone forgets about it? - N.

How are you launching that testcase? "mozilla -chrome test.html"?

roc: Yep, with -chrome as for the parent bug. Quotes and URLs like this: mozilla -chrome "file://C:/tmp/test.html" Sure, it's an odd thing to do, no argument about that. It's a test case. - N.