Closed
Bug 458898
Opened 16 years ago
Closed 16 years ago
Windows opened via openDialog function aren't visible in Firefox 3.1b1pre
Categories
(Core :: Layout, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b3
People
(Reporter: morac, Assigned: roc)
References
Details
(Keywords: fixed1.9.1, regression)
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
image/jpeg
|
Details |
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.
Reporter | ||
Comment 1•16 years ago
|
||
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•16 years ago
|
||
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?
Version: unspecified → Trunk
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
Comment 3•16 years ago
|
||
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).
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Updated•16 years ago
|
Assignee: jag → nobody
Updated•16 years ago
|
Component: XUL → DOM
QA Contact: xptoolkit.widgets → general
Updated•16 years ago
|
Assignee: nobody → jst
Comment 4•16 years ago
|
||
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
Assignee | ||
Comment 5•16 years ago
|
||
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.
Attachment #349705 -
Flags: superreview?(dbaron)
Attachment #349705 -
Flags: review?(dbaron)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review]
Assignee | ||
Comment 6•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #349915 -
Flags: superreview?(dbaron)
Attachment #349915 -
Flags: superreview+
Attachment #349915 -
Flags: review?(dbaron)
Attachment #349915 -
Flags: review+
Comment 7•16 years ago
|
||
Comment on attachment 349915 [details] [diff] [review]
fix v1.1
r+sr=dbaron
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Comment 8•16 years ago
|
||
Pushed 357d1c01bde3 to trunk
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite+
Comment 9•16 years ago
|
||
So if this was pushed to trunk its not on 1.9.1 FF3.1 correct?
Assignee | ||
Comment 10•16 years ago
|
||
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•16 years ago
|
||
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
Assignee | ||
Comment 12•16 years ago
|
||
Are you absolutely sure your build has the fix? That build ID is only 6 minutes after I pushed the patch...
Comment 13•16 years ago
|
||
Checking about:buildconfig, it sure looks like it includes your changes--at least your changes are listed.
Comment 14•16 years ago
|
||
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
Assignee | ||
Comment 15•16 years ago
|
||
OK. I think you should file a new bug about that (including a simple testcase if possible).
Comment 16•16 years ago
|
||
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.
Assignee | ||
Comment 17•16 years ago
|
||
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•16 years ago
|
||
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
Assignee | ||
Comment 19•16 years ago
|
||
I backed this out to try to fix random Windows orange (bug 467742).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [needs 191 landing] → [needs landing or new patch]
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite+
Comment 20•16 years ago
|
||
Moving this to the layout module.
Assignee: roc → nobody
Component: DOM → Layout
Priority: P3 → P2
QA Contact: general → layout
Updated•16 years ago
|
Assignee: nobody → roc
Assignee | ||
Comment 21•16 years ago
|
||
This was not the cause of the Windows orange.
Whiteboard: [needs landing or new patch] → [needs landing]
Comment 22•16 years ago
|
||
This bug breaks my FEBE extension. This will be fixed by the time 3.1 goes public, right?
Assignee | ||
Comment 23•16 years ago
|
||
Yeah, I just have to reland the fix.
Assignee | ||
Comment 24•16 years ago
|
||
Repushed 7c5b6ac942e0
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Comment 25•16 years ago
|
||
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 26•16 years ago
|
||
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•16 years ago
|
||
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?
Assignee | ||
Comment 28•16 years ago
|
||
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.
Assignee | ||
Comment 29•16 years ago
|
||
Marking FIXED because a real bug has been fixed here. Future work should happen in another bug to avoid confusion.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 30•16 years ago
|
||
So should another bug with same exact first post be opened?
The test case in comment 0 still fails.
Comment 31•16 years ago
|
||
Filed as Bug 469203
Reporter | ||
Comment 32•16 years ago
|
||
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.
Assignee | ||
Comment 33•16 years ago
|
||
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.
Assignee | ||
Comment 34•16 years ago
|
||
Pushed 378bf43994fa to 1.9.1
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.1b3
Comment 35•16 years ago
|
||
At least something seems to still go wrong here, as SeaMonkey fails the test added with this patch, see bug 469331.
Comment 36•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
(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/
You need to log in
before you can comment on or make changes to this bug.
Description
•