Closed Bug 559272 Opened 14 years ago Closed 12 years ago

Intermittent failure in test_bug511075.html | function () {

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

fix2 (checked in comment 24)
1.97 KB, patch
smaug
: review+
Details | Diff | Splinter Review 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271228116.1271230713.2455.gz
OS X 10.5.2 mozilla-central debug test mochitests-4/5 on 2010/04/13 23:55:16
s: moz2-darwin9-slave15

78391 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_bug511075.html | function () {
I need to do something to this. I'll try to look at this tomorrow.
Assignee: nobody → Olli.Pettay
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272498597.1272499872.26944.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/04/28 16:49:57
s: win32-slave27
NOTE: Comment 7 & Comment 8 are the same log.  (I'd thought TinderboxPushlog Robot refrained from posting when the log had already been posted, but it must have failed for some reason in this case.)
Attached patch fix? (obsolete) — — Splinter Review 
I think the problem is that the scroll-up arrow is not at
y-position 5px on MacOSX, it's below the slider together
with the scroll-down arrow, so what happens here is that
the click goes to the scrollbar background which scrolls
a page up, unless you're unfortunate and hit the slider
or the few pixels at the top that is dead.
(I would expect the failure to be more deterministic than
it appears to be though...)

Anyway, here's a possible fix which works for me locally.
Attachment #444022 - Flags: review?(Olli.Pettay)
Comment on attachment 444022 [details] [diff] [review]
fix?

Hmm, well, the top scroll arrow is below the slider in some setups.
Does this work with the other setup?
I think the top arrow button is below the slider by default on OSX.
Anyway, I tested this with all four values for AppleScrollBarVariant
and it works for me locally.  TryServer unit tests passed too.
Assignee: Olli.Pettay → matspal
Attachment #444022 - Attachment is obsolete: true
Attachment #444022 - Flags: review?(Olli.Pettay)
Attachment #445286 - Flags: review?(Olli.Pettay)
Comment on attachment 445286 [details] [diff] [review]
fix2 (checked in comment 24)

Let's try this.
Though, could you change the comment a bit, perhaps
"On MacOSX the top scroll arrow can be below the slider just above
the bottom scroll arrow."
Attachment #445286 - Flags: review?(Olli.Pettay) → review+
This should fix the failure on OSX:
http://hg.mozilla.org/mozilla-central/rev/30960da07185

Leaving the bug open for the failures on Windows.
Assignee: matspal → nobody
OS: Mac OS X → Windows XP
Attachment #445286 - Attachment description: fix2 → fix2 (checked in comment 24)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275077330.1275079398.23350.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/05/28 13:08:50
s: win32-slave29

81139 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_bug511075.html | function () {
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275099438.1275101922.21711.gz
Rev3 Fedora 12 mozilla-central debug test mochitests-4/5 on 2010/05/28 19:17:18
s: talos-r3-fed-028

81150 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_bug511075.html | function () {
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276743763.1276745243.1812.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/06/16 20:02:43
s: win32-slave27
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277192632.1277195508.26867.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/06/22 00:43:52
s: win32-slave42
> PROCESS-CRASH | Main app process exited normally | application crashed
(minidump found)
What does that mean? That the Main app (Firefox) exited normally, but that the plugin-container.exe crashed?

Anyway, this is the unexpected-fail error:
NEXT ERROR 82316 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_bug511075.html | function () {
    ok(true, "Clicking the top scroll arrow should scroll.");
    nextTest();
    var x = scroller.getBoundingClientRect().width - 5;
    var y = scroller.getBoundingClientRect().height - 25;
    synthesizeMouse(scroller, x, y, {type: "mousedown"}, window);

In bug 586655 I attached a patch, that makes things more general (not making assumptions about the scrollbar size). Perhaps it would help the random failure here.
The PROCESS-CRASH notifications are usually from intentional, expected plugin process crashes.
this hasn't been seen in over 6 months.  Can we close this bug?
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
This happened on integration/fx-team branch today,
http://tinderbox.mozilla.org/showlog.cgi?log=Fx-Team/1310581568.1310585134.22384.gz
Rev3 Fedora 12x64 fx-team debug test mochitests-4/5 on 2011/07/13 11:26:08

First time it happened on non-windows

s: talos-r3-fed64-026
101204 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_bug511075.html | function () {
Bug 559272 - Intermittent failure in test_bug511075.html | function () { TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_resizer.xul | Exited with code 1 during test run
PROCESS-CRASH | /tests/layout/xul/base/test/test_resizer.xul | application crashed (minidump found)
Thread 0 (crashed)
TEST-UNEXPECTED-FAIL | plugin process 2146 | automationutils.processLeakLog() | missing output line for total leaks!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Whiteboard: [orange] → [orange][fails infrequently, leave open, oh wfm-script]
Huh, so how did https://hg.mozilla.org/integration/mozilla-inbound/diff/8180cd29102a/layout/xul/base/test/Makefile.in which only changed from having another test in the same directory always be copied (because "mobile" as a MOZ_BUILD_APP was Android XUL) to having it still always be copied just like always cause this to fail in two separate runs on separate builds?
Ah, Ms2ger points out that https://hg.mozilla.org/integration/mozilla-inbound/diff/77b3b2868269/layout/xul/base/test/Makefile.in screwed up, and overwrote what was then called _TEST_FILES rather than +=ing it, so that for everything but Android XUL, we didn't actually run this or test_splitter.xul, so it's no surprise this stopped failing, and no surprise we didn't know it was permaorange on native Android, because we haven't run it at all for more than a year.
Blocks: 798806
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange][fails infrequently, leave open, oh wfm-script] → [orange]
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: