Closed Bug 458898 Opened 11 years ago Closed 11 years ago

Windows opened via openDialog function aren't visible in Firefox 3.1b1pre


(Core :: Layout, defect, P2, major)

Windows XP





(Reporter: morac, Assigned: roc)



(Keywords: fixed1.9.1, regression)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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("", "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 "" with "" 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("", "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:


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.
I see no obvious culprit. Bug 210094? or Bug 438987?
Version: unspecified → Trunk
Flags: blocking1.9.1?
Ever confirmed: true
Keywords: regression
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).
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Assignee: jag → nobody
Component: XUL → DOM
QA Contact: xptoolkit.widgets → general
Assignee: nobody → jst
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.
Assignee: jst → roc
Attached patch fix (obsolete) — Splinter Review
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("") 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.
Attachment #349705 - Flags: superreview?(dbaron)
Attachment #349705 - Flags: review?(dbaron)
Whiteboard: [needs review]
Attached patch fix v1.1Splinter Review
With testcase.
Attachment #349705 - Attachment is obsolete: true
Attachment #349915 - Flags: superreview?(dbaron)
Attachment #349915 - Flags: review?(dbaron)
Attachment #349705 - Flags: superreview?(dbaron)
Attachment #349705 - Flags: review?(dbaron)
Attachment #349915 - Flags: superreview?(dbaron)
Attachment #349915 - Flags: superreview+
Attachment #349915 - Flags: review?(dbaron)
Attachment #349915 - Flags: review+
Whiteboard: [needs review] → [needs landing]
Pushed 357d1c01bde3 to trunk
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Flags: in-testsuite+
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.

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.

I backed this out to try to fix random Windows orange (bug 467742).
Resolution: FIXED → ---
Whiteboard: [needs 191 landing] → [needs landing or new patch]
Flags: in-testsuite+
Moving this to the layout module.
Assignee: roc → nobody
Component: DOM → Layout
Priority: P3 → P2
QA Contact: general → layout
Assignee: nobody → roc
This was not the cause of the Windows orange.
Whiteboard: [needs landing or new patch] → [needs landing]
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.
Repushed 7c5b6ac942e0
Closed: 11 years ago11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
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")
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
Resolution: FIXED → ---
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.
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
So should another bug with same exact first post be opened? 
The test case in comment 0 still fails.
Filed as Bug 469203
Attached image Screenshot of problem
Result of the following command:
window.openDialog("", "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
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
Target Milestone: --- → mozilla1.9.1b3
Depends on: 469331
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" - ).  Was it supposed to be?  Will there be a 3.1b3?
Blocks: 455577
(In reply to comment #37)
> Will there be a 3.1b3?
Yes -- the beta 3 release is currently targeted at Jan 26, according to

If you want to test this, you're welcome to try the latest Firefox 3.1 nightly build, available at
Blocks: 472886
You need to log in before you can comment on or make changes to this bug.