Closed Bug 448132 Opened 12 years ago Closed 11 years ago

last set of y1/y4 tests in acid3 test 46 (media queries) fail on Windows

Categories

(Core :: Widget: Win32, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: robarnold)

References

Details

Attachments

(1 file, 1 obsolete file)

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 .
Flags: wanted1.9.1?
Flags: blocking1.9.1?
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
And note that while commenting out the code I cite in comment 2 (which fixes this bug) does not currently cause bug 56156, it does currently cause incorrect resizes to 0x0 (as shown by putting a printf at the start of PresShell::ResizeReflow), so we should have something here.
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-
Attached patch v1.0 (obsolete) — Splinter Review
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)
Ready to be landed?
I'm working on getting the test changes reverted and then I'll verify that it does fix the problem.
Attached patch v1.0 w/testsSplinter Review
I verified that my fix does fix the test. I'll push when the tree reopens.
Attachment #333432 - Attachment is obsolete: true
Ok, pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/af50e2f9c650
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 452794
Depends on: 455136
No longer depends on: 455136
Depends on: 454473
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.
This patch should be backed out, since it caused bug 454473 (blocking1.9+) and bug 452794.
For the record, this patch has been modified in bug 454473 and again in bug 502713.
You need to log in before you can comment on or make changes to this bug.