[Firefox] WinXP debug permaorange: "test_leaf_layers_partition_browser_window.xul | Leaf layers should form a non-overlapping partition of the browser window"

RESOLVED FIXED in mozilla6

Status

()

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: philor, Assigned: roc)

Tracking

(Blocks 1 bug)

Trunk
mozilla6
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [perma-orange], )

Attachments

(2 attachments)

Reporter

Description

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1299774157.1299777108.3542.gz&fulltext=1#err0
Rev3 WINNT 5.1 mozilla-central debug test mochitest-other on 2011/03/10 08:22:37
s: talos-r3-xp-020

...
7556 INFO TEST-PASS | chrome://mochitests/content/chrome/layout/base/test/chrome/test_leaf_layers_partition_browser_window.xul | Waiting for mozPaintCount to increase. - 0 should equal 0
7557 INFO TEST-PASS | chrome://mochitests/content/chrome/layout/base/test/chrome/test_leaf_layers_partition_browser_window.xul | mozPaintCount has increased - 1 should not equal 0
7558 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/layout/base/test/chrome/test_leaf_layers_partition_browser_window.xul | Leaf layers should form a non-overlapping partition of the browser window

No idea how to tell whether or not this is the same thing as bug 632408, where it permafails on SeaMonkey's (debug-only) Win2K3 boxes.
roc and tnikkel could we disable this test so we can unhide the whole suite?

I would like to reveal the suite while we figure out how to fix this test failure.
Blocks: 632408
Summary: WinXP debug permaorange: test_leaf_layers_partition_browser_window.xul | Leaf layers should form a non-overlapping partition of the browser window → [Firefox] WinXP debug permaorange: "test_leaf_layers_partition_browser_window.xul | Leaf layers should form a non-overlapping partition of the browser window"
Bug 632408 comment 5:
{
Timothy Nikkel (:tn)      2011-03-11 02:11:18 PST

If you set the environment variable MOZ_DUMP_PAINT_LIST to 1 you will get a lot
of paint debug output including a dump of the layer tree. The layer tree dump
would probably useful in determining why this is failing.
}
Keywords: qawanted
Whiteboard: [perma-orange] → [qaw: comment 2] [perma-orange]
So the reason this fails is that the resizer has a layer that overlaps the content layer. Windows Vista/7 resize via a thick border and don't have the resizer.
Whiteboard: [qaw: comment 2] [perma-orange] → [perma-orange]
Since on both XP and Vista/7 our browser window has significant differences we should probably run the test twice, once with a maximized window and once without. (XP has a resizer only when not maximized, and the tabs move up higher on a maximized window on Vista/7.)
The resizer layer is 17x17, so I don't think we have a problem here. The question is how to modify the test properly.
Reporter

Comment 6

8 years ago
This'll keep me from constantly badgering you about when you'll figure out a way to deal with the resizer, and when I can make the suite visible, and when you're going to work on it, and how the work on it is going, and whether you've come up with an idea yet, and when...
Attachment #518996 - Flags: review?(tnikkel)
Attachment #518996 - Flags: review?(tnikkel) → review+
(In reply to comment #5)
> The resizer layer is 17x17, so I don't think we have a problem here. The
> question is how to modify the test properly.

Let's just not run the non-fullscreen test on < Vista.
Is there an (easy) way to maximize a window? I spent some time looking but failed to find a way.
Thanks Phil!
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
There were a couple of green mozilla2.0 cycles before this landed (despite summary claiming permaorange), and since then we've seen bug 637975 as a perma-orange
Reporter

Comment 23

8 years ago
Excuse me? Neither one of those assertions seems to be at all true. Log links or it didn't happen.
(In reply to comment #25)

Looks like mrbkap backed some stuff out to fix those failures.
Assignee: nobody → roc
Attachment #532599 - Flags: review?(tnikkel) → review+
Whiteboard: [perma-orange] → [perma-orange][needs landing]
Pushed once:
http://hg.mozilla.org/mozilla-central/rev/c0f9a84ffb2d

Then backed out because the bug number was incorrect:
http://hg.mozilla.org/mozilla-central/rev/1205e0437f0a

Then pushed again:
http://hg.mozilla.org/mozilla-central/rev/f792fa7755dc
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [perma-orange][needs landing] → [perma-orange]
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.