User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081007 Minefield/3.1b1pre Windows that are opened via the window.openDialog function are not displaying in Firefox 3.1b1pre. They appear to actually be opening, but are invisible. This is a regression from Firefox 3.0.3. Reproducible: Always Steps to Reproduce: 1. In the error console type: window.openDialog("http://www.yahoo.com", "Window", "modal") Actual Results: The error console loses focus as if a modal dialog window opened, but the window is not visible. Expected Results: A dialog window should have opened and displayed the Yahoo homepage like it does in Firefox 3.0.3. If the "modal" parameter is left out, then the window still won't display, but there will be a "Yahoo" Firefox tab in the Windows status bar. Clicking it does nothing since the window is hidden. For some reason if I replace "http://www.yahoo.com" with "http://www.google.com" and window that displays only the "Google" title bar will display and the window can be resized to display the Google homepage. While this window is displaying if I then issue the window.openDialog("http://www.yahoo.com", "Window", "modal") command, the window that was displaying Google starts to load Yahoo and then the window "vanishes" from the desktop. There are after-images of it being there, but the window itself is gone. At this point Firefox is unstable.
I found an even easier way to show this. Just type the following in the error console: window.openDialog("about:blank") In Firefox 3.0.3, a blank window opens. In Firefox 3.1b1pre, a window with 0 width and height opens so it's invisible and unusable. There is no way to resize it since resizeTo doesn't appear to work.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006 Minefield/3.1b1pre I see a sudden change between these two builds: 20080808000915 and 20080808031528 while testing your window.openDialog("about:blank") The first displayed a very small 4 cm wide window and the latter only an empty taskbar button. http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=08%2F07%2F2008&enddate=08%2F08%2F2008 I see no obvious culprit. Bug 210094? or Bug 438987?
As I commented in bug 451880 this problem is breaking my extension WriteArea (it was a side comment because in that moment the most important part was the crash).
This was caused by commit ca7bb3f59be1 which was roc's fix for bug 438987. Pulling before that change and calling openDialog("about:blank") creates a blank dialog, as expected, pulling with that change makes us open a window with nothing in it, you can see through it and even click through it. Reassigning to Roc.
Created attachment 349705 [details] [diff] [review] fix I think this is the right fix. DocumentViewerImpl::SizeToContent does a resize-reflow with NS_UNCONSTRAINEDSIZE height, which gets passed down as the computed height for the canvas. In that case we need to return a real height instead of returning NS_UNCONSTRAINEDSIZE as the desired height. With that fixed, openDialog("www.yahoo.com") and openDialog("about:blank") create visible windows, although I can't say the results are very satisfactory, but I guess that's not the point.
Created attachment 349915 [details] [diff] [review] fix v1.1 With testcase.
Pushed 357d1c01bde3 to trunk
So if this was pushed to trunk its not on 1.9.1 FF3.1 correct?
Not yet, but I plan to land it on 1.9.1 after it's baked on trunk for a couple of days.
This does not appear to be fully fixed. The WriteArea extension window appears, but it is off-screen and inaccessible. All that is visible is the entry on the Windows taskbar. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081202 Minefield/3.2a1pre ID:20081202152844
Are you absolutely sure your build has the fix? That build ID is only 6 minutes after I pushed the patch...
Checking about:buildconfig, it sure looks like it includes your changes--at least your changes are listed.
Just retested with a newer build and a clean profile. Same problem. http://hg.mozilla.org/mozilla-central/rev/c6b884676c0d Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081202 Minefield/3.2a1pre ID:20081202162911
OK. I think you should file a new bug about that (including a simple testcase if possible).
Maybe Alfonso Martinez, or the original reporter, is the best person to assess whether to file a new bug. According to Comment #1, if the "modal" parameter is left out of the window.openDialog call, the problem I'm seeing occurs. Therefore, since I am not a skilled programmer, I am unable to determine whether the extension should be updated or if this bug still needs work. Given that this problem is a regression, and the Write Area extension works properly with 3.0.x, I'm inclined to believe the fix is still inadequate; however, since the problem I am reporting was already originally part of this bug report, I'm not sure what to make of why that isn't part of this bug fix.
The problems described in comment #0 and comment #1 are fixed for me on Mac. If WriteArea is still broken somehow, then either this bug remains unfixed on your platform, whatever that is, or there is another bug.
Then I guess it remains broken on Windows--the platform against which the bug was reported. So is it still appropriate to consider this resolved? :-) Anyways, I'll let the other more qualified individuals look into it. Thanks
I backed this out to try to fix random Windows orange (bug 467742).
Moving this to the layout module.
This was not the cause of the Windows orange.
This bug breaks my FEBE extension. This will be fixed by the time 3.1 goes public, right?
Yeah, I just have to reland the fix.
The problem with the WriteArea extension still exists, I guess that it might affect any extension trying to load a chrome: page with openDialog. An easy test to check that the problem persists and isn't due to a problem in the extension is loading window.openDialog("about:blank", "Window", "width=780,height=500") or window.openDialog("about:blank", "Window", "modal") I guess that this build has the fix because now yahoo loads. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre
I would have to agree that the problem is not fixed based on the two test cases above: Entering the following into the error console does not open a window, but opens a task bar button: window.openDialog("about:blank", "Window", "width=780,height=500") Entering the following appears to open nothing, but makes it impossible to interact with or close the error console as if there is a invisible modal window open: window.openDialog("about:blank", "Window", "modal") On a side note, if I choose the "File->Exit" why the hidden modal window is open, it appears to close and the error console unfreezes and displays the text "[object ChromeWindow]". I can then close the error console. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre
At least in my case, the results from openWindow() in FF3.1 depend upon when the call is made. If I make the call 'early', window is busted, if I call after my app is up, all is good. Maybe this explains the fixed/not fixed differences?
Opening about:blank creates a very small window. are you sure you didn't just lose it somewhere? > window.openDialog("about:blank", "Window", "width=780,height=500") This works for me on Mac. Is it possible there is a separate Windows-only issue? We already fixed a real bug here in this bug. To avoid confusion, it's best to open a new bug for whatever issues are remaining. Someone please do that.
Marking FIXED because a real bug has been fixed here. Future work should happen in another bug to avoid confusion.
So should another bug with same exact first post be opened? The test case in comment 0 still fails.
Filed as Bug 469203
Created attachment 352598 [details] Screenshot of problem 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.
That's a different problem. The window has opened with a reasonable size, but it's not being painted. Before this fix it opened with size zero or thereabouts. Also, that command works for me on Mac now, so the remaining problem is platform dependent. Thanks for filing that bug, Alfonso.
Pushed 378bf43994fa to 1.9.1
At least something seems to still go wrong here, as SeaMonkey fails the test added with this patch, see bug 469331.
Actually, when I try the case from comment #0 of this bug in my current Shiretoko, I see the web page being laid out over the whole screen, without any chrome and with transparent background. Whatever was fixed ion here is not the bug that was initially reported here and I still fail to understand who the test added here ca work as manually calling what it calls does fail without showing the window in my Shiretoko as well.
This was not fixed in the December 8, 2008 release of Fx 3.1b2 (nor is it mentioned in the "Known issues" - http://en-us.www.mozilla.com/en-US/firefox/3.1b2/releasenotes/ ). Was it supposed to be? Will there be a 3.1b3?
(In reply to comment #37) > Will there be a 3.1b3? Yes -- the beta 3 release is currently targeted at Jan 26, according to https://wiki.mozilla.org/WeeklyUpdates/2009-01-05#Firefox_3.1 If you want to test this, you're welcome to try the latest Firefox 3.1 nightly build, available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/