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

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Michael Kraft [:morac]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) 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.

Comment 1

[Michael Kraft [:morac]]

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.

Comment 2

[Ria Klaassen (not reading all bugmail)]

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?

Comment 3

[Alfonso Martinez]

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).

Comment 4

[Johnny Stenback (: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.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v1.1

With testcase.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 349915 [details] [diff] [review]
fix v1.1

r+sr=dbaron

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed 357d1c01bde3 to trunk

Comment 9

[John J. Barton]

So if this was pushed to trunk its not on 1.9.1 FF3.1 correct?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Not yet, but I plan to land it on 1.9.1 after it's baked on trunk for a couple of days.

Comment 11

[IU]

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

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are you absolutely sure your build has the fix? That build ID is only 6 minutes after I pushed the patch...

Comment 13

[IU]

Checking about:buildconfig, it sure looks like it includes your changes--at least your changes are listed.

Comment 14

[IU]

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

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK. I think you should file a new bug about that (including a simple testcase if possible).

Comment 16

[IU]

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.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 18

[IU]

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

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I backed this out to try to fix random Windows orange (bug 467742).

Comment 20

[Johnny Stenback (:jst)]

Moving this to the layout module.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This was not the cause of the Windows orange.

Comment 22

[Chuck Baker]

This bug breaks my FEBE extension.  This will be fixed by the time 3.1 goes public, right?

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, I just have to reland the fix.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Repushed 7c5b6ac942e0

Comment 25

[Alfonso Martinez]

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

Comment 26

[Michael Kraft [:morac]]

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

Comment 27

[John J. Barton]

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?

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Marking FIXED because a real bug has been fixed here. Future work should happen in another bug to avoid confusion.

Comment 30

[Michael Kraft [:morac]]

So should another bug with same exact first post be opened? 
The test case in comment 0 still fails.

Comment 31

[Alfonso Martinez]

Filed as Bug 469203

Comment 32

[Michael Kraft [:morac]]

Attachment: 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.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed 378bf43994fa to 1.9.1

Comment 35

[Robert Kaiser]

At least something seems to still go wrong here, as SeaMonkey fails the test added with this patch, see bug 469331.

Comment 36

[Robert Kaiser]

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.

Comment 37

[Chuck Baker]

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?

Comment 38

[Daniel Holbert [:dholbert]]

(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/