Closed Bug 448132 Opened 13 years ago Closed 13 years ago
last set of y1/y4 tests in acid3 test 46 (media queries) fail on Windows
The last set of y1/y4 tests in test 46 of acid3 fail on Windows only. I'm guessing it's something related to the delayed resizing stuff or hidden visibility for when we size windows to 0x0. This is tested in both http://acid3.acidtests.org/ and layout/style/test/test_acid3_test46.html .
The test changes that should be reverted when this is fixed are: http://hg.mozilla.org/mozilla-central/index.cgi/rev/4dee7a278399 http://hg.mozilla.org/mozilla-central/index.cgi/rev/d0e438d64ea0
Commenting out this code fixes the problem: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow.cpp&rev=3.745&mark=4880-4886#4879
The code in question was added for bug 56156: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/widget/src/windows/nsWindow.cpp&mark=3.297#3.297
So I think this chunk of code needs a better test for being minimized than (newHeight==0 && newWidth==0). There's in fact a big chunk of code right below the code causing the problem that deals with size mode changes. (Interestingly, the code that's causing the problem seems like it probably *also* causes us to skip that code.) It would be great if I could talk somebody else into figuring out what the right thing to do here is...
Component: Style System (CSS) → Widget: Win32
QA Contact: style-system → win32
To be clear, what I was trying to say in comment 5 is that we do still need code to suppress the resizes that result from being minimized. We just need to fix that code so that it doesn't suppress other resizes.
Rob would love to work on this.
Assignee: nobody → tellrob
Flags: wanted1.9.1? → wanted1.9.1+
Priority: -- → P1
Flags: blocking1.9.1? → blocking1.9.1-
This does exactly what David suggested in comment 6. I'm not sure why there are minimized child windows at all
Attachment #333432 - Flags: review?(vladimir)
Attachment #333432 - Flags: review?(vladimir) → review+
Ready to be landed?
I'm working on getting the test changes reverted and then I'll verify that it does fix the problem.
I verified that my fix does fix the test. I'll push when the tree reopens.
Attachment #333432 - Attachment is obsolete: true
The tree is already open http://tinderbox.mozilla.org/Firefox/
Ok, pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/af50e2f9c650
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
This seems to have caused bug 454473 -- the regression is fairly bad, potentially bad enough to cause this to be backed out.
Sounds like the patch didn't do comment 6 correctly, then.
I wonder if we're getting a 0x0 resize before the iconic state is set on the window? That would cause it, I think.
I'm not sure why IsIconic wouldn't have the right return value, but we could try checking wp->flags for SWP_HIDEWINDOW or call ::GetWindowPlacement as is done just a bit further down. The former is easier, but I suspect the latter may be more correct.
You need to log in before you can comment on or make changes to this bug.