Closed Bug 337859 Opened 14 years ago Closed 14 years ago

Firefox windows open very small initially, then expand to regular size

Categories

(Firefox :: General, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: ispiked, Assigned: ginnchen+exoracle)

References

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:
1. Open Firefox.

Results:
Window is sized around 100x100px and then resizes to normal window size very quickly.

Expect results:
Open in normal window size.

Regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-12+11%3A00&maxdate=2006-05-12+21%3A00&cvsroot=%2Fcvsroot
This is a regression from bug 336847; verified by local backout of that patch.
I've not seen this at all here, and it's got to be a layout bug...
Very possible, but it looks like crap, fucks with the window manager's placement algorithms, and the Firefox window doesn't make a very good layout bug testcase.  If someone can come up with a minimal-ish XUL testcase, that would be nice.

For what it's worth, I really don't see why this CSS change would cause this behavior; I'd think the window size would come from the persistence object... On the other hand, XUL's support for negative margins is not exactly well-tested, so...
Flags: blocking1.9a1+
reverting bug 295447 (and subsequent fixes to it) by commenting out http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsWindow.cpp#715 -- 719 fixes this issue also (cf bug 324348)
I'm sorry to hear this bug returns.
The CSS changes make mNeedsResize become FALSE before the window is focused.
Attached patch patchSplinter Review
We should check owningWindow's attribute, not |this|'s.
I think mIsShown is much more reliable than mNeedsResize
Assignee: nobody → ginn.chen
Status: NEW → ASSIGNED
Attachment #222152 - Flags: review?(roc)
I can confirm that the patch fixes things here. Note while testing that since the css that triggered this issue gives incorrect appearance on gtk (bug 338000), it may go away due to changes there.
Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.172; previous revision: 1.171
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.