Open Bug 626563 Opened 12 years ago Updated 1 month ago

[SeaMonkey] mochitest-plain-5: "test_arrowpanel.xul | panel arrow side - got "bottom", expected "top"" (with lots of "ASSERTION: Popup is offscreen")


(SeaMonkey :: General, defect)



(blocking2.0 -)

Tracking Status
blocking2.0 --- -


(Reporter: sgautherie, Unassigned)


(Blocks 1 open bug, )


(Keywords: assertion, Whiteboard: [perma-orange])

Two months ago, I fixed this test in bug 611231.
Today, after fixing bug 626294, a new failure was revealed.

Linux doesn't run this test.
MacOSX(64) and Windows are affected:
WINNT 5.2 comm-central-trunk debug test mochitests-5/5 on 2011/01/17 17:32:48
7649 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | panel arrow side - got "bottom", expected "top"

Note that this test is (now) spamming with
###!!! ASSERTION: Popup is offscreen: 'screenPoint.x >= screenRect.x && screenPoint.y >= screenRect.y && screenPoint.x + mRect.width <= screenRect.XMost() && screenPoint.y + mRect.height <= screenRect.YMost()', file e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp, line 1279
xul!nsMenuPopupFrame::LayoutPopup+0x00000000000001F6 (e:\builds\slave\comm-cen-trunk-w32-dbg\build\mozilla\layout\xul\base\src\nsmenupopupframe.cpp, line 452)
Whiteboard: [perma-orange]
(In reply to comment #0)
> Today, after fixing bug 626294, a new failure was revealed.

Bug 616607 added a new 'input' test:
*when run alone: panel is below the input, as expected by the check.
*when run in the harness iframe: panel is above the input :-/
On my Windows 2000:

a) iframe top="180":
this bug.

b) iframe top="135":
panel is below, as expected by the check :-)

c) iframe top="155":
panel is above with arrow on top, as if bug 616607 wasn't (fully) fixed :-/
(Yet, the test passes :-<)

Now, I'm double-confused:

1) it seems (from a very quick read of bug 616607) that the check should be designed so the panel is expected above the input, not below.
Actually, the failing log is "got "bottom", expected "top"", as if the display is correct but the check gets "reversed" values :-/

2) it seems a bug 616607 (-like) issue remains.
blocking2.0: --- → ?
OK, so I tested a) by resizing the browser with the test loaded into it and b) by loading the test into differently sized frames, and on my PC the test fails if its window inner height is less than 325 pixels and succeds if it is 325 pixels or higher. And of course the harness frame is only 300 pixels high...
(In reply to comment #3)
> succeds

I still get the assertions when it succeeds, so maybe they're not relevant.
The assertions are caused by the popup flipping code not handling negative margins. For instance:

/ \_______________________________
The negative margin pushes this  |
panel off the left of the screen.|

In this configuration, because the popup is to the left of the screen, the flipping code thinks that it needs to be flipped to the right of the anchor.
You'll likely want the patch in bug 524545 for this.
That only gets rid of the unrelated assertions. It doesn't stop the test from failing because it wants a bigger iframe.
In fact, with the patch applied, things are even worse, since there are two tests that only work in a maximised window (or in a normal size window that's slightly off the right-hand side of the screen).
Depends on: 524545
blocking2.0: ? → -
So, I built Firefox.

And I actually get 17 failures on this test...
(In reply to comment #9)
> So, I built Firefox.
> And I actually get 17 failures on this test...

Ftr, see bug 625561 about Firefox ;->
Depends on: 626561
(In reply to comment #10)
> Ftr, see bug 625561 about Firefox ;->

Arf, bug 626561 !
As far as I can tell, this is now blocking bug 659350.  Every single test run with the patches for that bug has this failure on try....

Neil, any idea why the changes there would cause this to be permaorange in Firefox?
Blocks: 659350
Given comment 3, I also don't understand how this can possibly be green on Tinderbox... what gives?
I think we should just disable the part of the test that fails. (the part that was added by ) as it's caused no end of problems, and instead move it into a separate test.

The particular test in question relies on arrow panel positioning inside nested frames.
That's ok by me, but I'm still not sure why my changes trigger it reliably... they shouldn't really affect this, I'd think.
(In reply to TinderboxPushlog Robot from comment #13)
> gz
> Rev3 Fedora 12 try debug test mochitests-5/5 on 2011/08/04 23:05:51

7403 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | anchor - [object HTMLInputElement @ 0xa22a588 (native @ 0xbc84558)] should equal [object HTMLInputElement @ 0xa22a588 (native @ 0xbc84558)]
7404 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | panel arrow side - got "bottom", expected "top"
7405 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | panel hidden - false should equal false
7406 INFO TEST-END | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | finished in 2239ms

(In reply to Boris Zbarsky (:bz) from comment #15)
> Given comment 3, I also don't understand how this can possibly be green on
> Tinderbox... what gives?
Rev3 Fedora 12 mozilla-central debug test mochitests-5/5 on 2011/08/05 12:45:36
7256 INFO TEST-START | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul
7257 INFO TEST-END | /tests/toolkit/content/tests/widgets/test_arrowpanel.xul | finished in 136ms

I would guess your patch in bug 659350 is eventually fixing bug 626561 (see comment 9 to 11)...
disable part of the arrowpanels test that tends to fail

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

Moving this into the seamonkey component then.

Component: XUL Widgets → General
Product: Toolkit → SeaMonkey
You need to log in before you can comment on or make changes to this bug.