For previous comments see bug 458898 In the error console run this: window.openDialog("about:blank", "Window", "width=780,height=500") or window.openDialog("about:blank", "Window", "modal") This bug is affecting also extensions like Write Area or FEBE

Result of the following command: window.openDialog("http://www.yahoo.com", "Window", "modal") Note that the only thing that can be seen of the browser window is the scroll bars. The actual window and contents are transparent. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre

window.openDialog("http://www.yahoo.com", "Window", "modal") seems to work fine on Mac. So do window.openDialog("about:blank", "Window", "modal") and window.openDialog("about:blank", "Window", "modal") (although the latter creates a very tiny window that's hard to find). So I think this is now a Windows-only bug.

sounds like this blocks at least one addon from being compat with 3.1. see bug 411784. have we decided on blocking status, or what we are going to do with this bug?

I'll need to confirm with dbaron, but I'm quite sure this will get blocking status.

This block FF3.1b2 with "abcTajpu" extension (although the "traduku" extension which also uses openDialog (though in a simpler way with .writes rather than load via chrome:ext/bla/some.html) does seem to work without blocking).

I think this may be a duplicate of 465993

It should be noted that this bug affects Thunderbird v3.0b1 also.

window.openDialog("http://www.yahoo.com", "Window", "modal") worked just fine for me in my trunk WinXP build. Here's a screenshot. OK, some bits of Yahoo loaded in a strange way but that's not what this bug is about, I guess.

However, the examples in comment #0 window.openDialog("about:blank", "Window", "width=780,height=500") window.openDialog("about:blank", "Window", "modal") don't work for me. The window is invisible.

(In reply to comment #8) > Created an attachment (id=353185) [details] > screenshot > > window.openDialog("http://www.yahoo.com", "Window", "modal") worked just fine > for me in my trunk WinXP build. Here's a screenshot. OK, some bits of Yahoo > loaded in a strange way but that's not what this bug is about, I guess. Right, the same problem exists in Firefox 3.0.4, and there might be another bug to track it (I didn't care to search it as it might be specific to the way the page is created, all that html seems to be 1x1 tracking images).

OK, the key problem here is that opening about:blank (or any document without an explicit background-color) creates a window in translucent mode! And HTML documents don't really support that so things go very wrong. If you open an HTML document with an explicit background color on the HTML or BODY elements, it should work fine. I'm not 100% sure what to do about this. I suppose for now we should force non-XUL root chrome documents to get the default background color that they'd get if they were top-level content documents.

(In reply to comment #11) > OK, the key problem here is that opening about:blank (or any document without > an explicit background-color) creates a window in translucent mode! By observation, I can confirm that this is the case. With the Write Area extension activated by choosing "Edit in a Write Area" from a textarea, when you right-click the window-less Write Area entry on the Windows Taskbar, choose Size, and then slowly move your mouse around the top-left area of the screen, you can trace out the invisible window, as the mouse pointer changes to the resize pointers.

On Windows XP at least, window transparency doesn't work well with child windows, so when the document root is scrollable (which all non-XUL-root documents are, except for framesets) there's a widget for the scrollport which messes everything up. So we may as well restrict transparent/translucent toplevel windows to those whose root element is a XUL element, at least until translucent HTML windows work better. Most of the patch is just restructuring this function.

Aside from this fix, it would be good if extension authors used documents with background colors so they don't start getting transparent documents at some point in the future. Although if we make translucent HTML documents work properly, so that the content is actually rendered, at least it will be obvious what's going on when a window starts being translucent.

Comment on attachment 353647 [details] [diff] [review] fix r+sr=dbaron

Pushed 295ef42f86d4

I can confirm that this is now fixed with respect to the "Write Area" extension.

Just an FYI, This issue was seen in Shredder 3.0b2pre before Christmas, when I was evaluating the ViewAbout extension and the About: feature of MR Tech Toolkit extension. I was seeing some about: dialogs that were invisible but for scroll bar or mouse pointer swap tracing. Glad to read this was found in core and worked on.

Pushed f8e4d4e71b88 to 1.9.1

Feedback that the fix worked for the invisible about:cache in Shredder. Thank You for solving this bug.

Fix now properly displays dialog windows in TEBE with Shredder 01/10 nightly.