Last Comment Bug 458898 - Windows opened via openDialog function aren't visible in Firefox 3.1b1pre
: Windows opened via openDialog function aren't visible in Firefox 3.1b1pre
Status: RESOLVED FIXED
: fixed1.9.1, regression
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows XP
: P2 major (vote)
: mozilla1.9.1b3
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
: Jet Villegas (:jet)
Mentors:
Depends on: 469331
Blocks: 455577 472886
  Show dependency treegraph
 
Reported: 2008-10-07 08:54 PDT by Michael Kraft [:morac]
Modified: 2009-01-09 13:13 PST (History)
14 users (show)
roc: blocking1.9.1+
roc: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (2.47 KB, patch)
2008-11-23 21:05 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v1.1 (4.49 KB, patch)
2008-11-24 19:47 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review
Screenshot of problem (170.53 KB, image/jpeg)
2008-12-11 13:43 PST, Michael Kraft [:morac]
no flags Details

Description User image Michael Kraft [:morac] 2008-10-07 08:54:34 PDT
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 User image Michael Kraft [:morac] 2008-10-07 09:45:35 PDT
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 User image Ria Klaassen (not reading all bugmail) 2008-10-07 13:41:49 PDT
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 User image Alfonso Martinez 2008-10-15 02:43:29 PDT
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 User image Johnny Stenback (:jst, jst@mozilla.com) 2008-11-20 18:48:17 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-23 21:05:26 PST
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.
Comment 6 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-24 19:47:32 PST
Created attachment 349915 [details] [diff] [review]
fix v1.1

With testcase.
Comment 7 User image David Baron :dbaron: ⌚️UTC-8 2008-12-01 15:00:54 PST
Comment on attachment 349915 [details] [diff] [review]
fix v1.1

r+sr=dbaron
Comment 8 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-02 13:30:18 PST
Pushed 357d1c01bde3 to trunk
Comment 9 User image John J. Barton 2008-12-02 15:34:10 PST
So if this was pushed to trunk its not on 1.9.1 FF3.1 correct?
Comment 10 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-02 15:39:26 PST
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 User image IU 2008-12-02 18:05:47 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-02 18:17:09 PST
Are you absolutely sure your build has the fix? That build ID is only 6 minutes after I pushed the patch...
Comment 13 User image IU 2008-12-02 18:39:02 PST
Checking about:buildconfig, it sure looks like it includes your changes--at least your changes are listed.
Comment 14 User image IU 2008-12-02 19:08:57 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-02 19:53:03 PST
OK. I think you should file a new bug about that (including a simple testcase if possible).
Comment 16 User image IU 2008-12-02 20:56:26 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-02 21:09:52 PST
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 User image IU 2008-12-02 21:15:31 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-03 03:45:44 PST
I backed this out to try to fix random Windows orange (bug 467742).
Comment 20 User image Johnny Stenback (:jst, jst@mozilla.com) 2008-12-03 15:28:39 PST
Moving this to the layout module.
Comment 21 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-04 19:07:19 PST
This was not the cause of the Windows orange.
Comment 22 User image Chuck Baker 2008-12-04 19:22:01 PST
This bug breaks my FEBE extension.  This will be fixed by the time 3.1 goes public, right?
Comment 23 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-04 19:32:21 PST
Yeah, I just have to reland the fix.
Comment 24 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-08 17:58:36 PST
Repushed 7c5b6ac942e0
Comment 25 User image Alfonso Martinez 2008-12-11 13:10:31 PST
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 User image Michael Kraft [:morac] 2008-12-11 13:23:16 PST
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 User image John J. Barton 2008-12-11 13:27:31 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-11 13:34:15 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-11 13:35:06 PST
Marking FIXED because a real bug has been fixed here. Future work should happen in another bug to avoid confusion.
Comment 30 User image Michael Kraft [:morac] 2008-12-11 13:37:48 PST
So should another bug with same exact first post be opened? 
The test case in comment 0 still fails.
Comment 31 User image Alfonso Martinez 2008-12-11 13:42:31 PST
Filed as Bug 469203
Comment 32 User image Michael Kraft [:morac] 2008-12-11 13:43:52 PST
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.
Comment 33 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-11 13:48:49 PST
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 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-12 01:09:31 PST
Pushed 378bf43994fa to 1.9.1
Comment 35 User image Robert Kaiser 2008-12-13 05:44:21 PST
At least something seems to still go wrong here, as SeaMonkey fails the test added with this patch, see bug 469331.
Comment 36 User image Robert Kaiser 2008-12-14 13:11:40 PST
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 User image Chuck Baker 2008-12-15 12:17:11 PST
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 User image Daniel Holbert [:dholbert] 2009-01-08 14:29:29 PST
(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/

Note You need to log in before you can comment on or make changes to this bug.