The default bug view has changed. See this FAQ.

[Linux] Intermittent Chrome test_bug418874.xul failure

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Toolkit
XUL Widgets
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: sgautherie, Assigned: graememcc)

Tracking

(Depends on: 1 bug, {fixed1.9.1, intermittent-failure})

Trunk
mozilla1.9.2a1
x86
Linux
fixed1.9.1, intermittent-failure
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed1.9.1b4])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
I already filed bug 472302, which was morphed and fixed,
yet Linux SeaMonkey still has this issue:

See bug 472302 comment 20, bug 472302 comment 21 and
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1234134281.1234138622.29877.gz
Linux comm-central dep unit test on 2009/02/08 15:04:41

*** 5302 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | undo correctly enabled when emptyText was not changed through property
*** 5304 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | undo correctly enabled when emptyText explicitly changed through property
}
Flags: wanted1.9.1?

Updated

8 years ago
Blocks: 418874
(Assignee)

Comment 1

8 years ago
Created attachment 364651 [details] [diff] [review]
Add some more output

Failed again this morning on Firefox trunk.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1235800277.1235805155.24753.gz

We seem to be worse off since bug 472302 - when this fails, we now have two failures rather than one.

Dão, what would you think about adding some extra spew to confirm the textboxes are in the state they're supposed to be in?
Attachment #364651 - Flags: review?(dao)
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)

Then, Firefox too and trunk too.
Summary: [SeaMonkey, Linux] intermittent Chrome test_bug418874.xul failure → [Linux] Intermittent Chrome test_bug418874.xul failure
Version: 1.9.1 Branch → Trunk
(Reporter)

Comment 3

8 years ago
Comment on attachment 364651 [details] [diff] [review]
Add some more output

>+      is(t1CanUndo.value, true,
>+         "undo correctly enabled when emptyText was not changed through property");

>+      is(t2CanUndo.value, true,
>+         "undo correctly enabled when emptyText explicitly changed through property");

You could add 't*CanUndo.value' to the text, to be even more explicit.
(Reporter)

Comment 4

8 years ago
Comment on attachment 364651 [details] [diff] [review]
Add some more output

>+      ok(true, "t1 value is "+t1.value);

>+      ok(true, "t2 value is "+t2.value);

And spaces around the operator.
Comment on attachment 364651 [details] [diff] [review]
Add some more output

>+      ok(true, "t1 value is "+t1.value);

Why not is(t1.value, ..., "t1 value");?

>-      ok(t1CanUndo.value, "undo correctly enabled when emptyText was not changed through property");
>+      is(t1CanUndo.value, true,
>+         "undo correctly enabled when emptyText was not changed through property");

What's the point of this change?
Failed again:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1236051486.1236057120.27846.gz
Whiteboard: [orange]
(Assignee)

Comment 7

8 years ago
Created attachment 365932 [details] [diff] [review]
Debug spew v2 (checked in)

Apologies for the delay coming back to this - day job/real life getting in the way.

> What's the point of this change?

Paranoia, mostly. I want to be sure that it is still a timing issue, and want to rule out a failure in the canUndo call, so I want to be sure that it is indeed the case that t*.canUndo.value == false, and not undefined/null.
Attachment #364651 - Attachment is obsolete: true
Attachment #364651 - Flags: review?(dao)
(Reporter)

Updated

8 years ago
Attachment #365932 - Flags: review?(dao)

Updated

8 years ago
Attachment #365932 - Flags: review?(dao) → review-
Comment on attachment 365932 [details] [diff] [review]
Debug spew v2 (checked in)

ok(a, "") is equivalent to is(a, true, "")... at least for true/false/null/undefined.
(Reporter)

Comment 9

8 years ago
Still there:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1236406575.1236413545.9435.gz
Linux mozilla-central unit test on 2009/03/06 22:16:15
(Reporter)

Comment 10

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1236413248.1236417995.18404.gz
Linux comm-central dep unit test on 2009/03/07 00:07:28
Is there any new data in the logs? If not, there's no need to link to more of them.
(Assignee)

Comment 12

8 years ago
> ok(a, "") is equivalent to is(a, true, "")... at least for
> true/false/null/undefined.

Yes, but I don't want the type conversion...that will give us no more information than we have already -  I want the debug spew to report exactly what canUndo holds at that point, to help narrow down what's failing.
Oh, so you want to get "got foo, expected bar" back. Because for the actual test, the type conversion happens either way...

Updated

8 years ago
Attachment #365932 - Flags: review- → review+
Comment on attachment 365932 [details] [diff] [review]
Debug spew v2 (checked in)

http://hg.mozilla.org/mozilla-central/rev/03e0942bcb90

> Is there any new data in the logs? If not, there's no need to link to more of
> them.

Now if you see it fail again, please do comment, as we need the new data :)
Attachment #365932 - Attachment description: Debug spew v2 → Debug spew v2 (checked in)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1236583027.1236589047.9553.gz&fulltext=1#err0
(Reporter)

Comment 16

8 years ago
(In reply to comment #15)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1236583027.1236589047.9553.gz&fulltext=1#err0

{
*** 780 INFO Running chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul...
NEXT ERROR *** 781 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | t1 value correct following input - got "", expected "1"
*** 782 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | undo correctly enabled when emptyText was not changed through property - got false, expected true
*** 783 INFO TEST-PASS | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | updated emptyText displayed
*** 784 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | t2 value correct following input - got "", expected "2"
*** 785 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_bug418874.xul | undo correctly enabled when emptyText explicitly changed through property - got false, expected true
}
http://hg.mozilla.org/mozilla-central/rev/2d6e148e8122
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/31f0a9854d39

let's see if it sticks.
Assignee: nobody → dao
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

8 years ago
No longer blocks: 472302

Updated

8 years ago
Flags: wanted1.9.1?
(Reporter)

Comment 18

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1237055635.1237060410.14003.gz
Linux comm-central dep unit test on 2009/03/14 11:33:55

Bug still there.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [orange] → [fixed1.9.1b4] [orange]
Target Milestone: --- → mozilla1.9.2a1
What's the ALSA lib conf.c stuff about? I'd consider this fixed until it comes back without other bogus stuff outside of this test.
The ALSA spew is just bug 469635 not being hacked-around on the SM box(es). That same spew is actually happening in every run (success or failure) on the Fx boxes, too, it's just getting sent to /dev/null there.
(Reporter)

Comment 21

8 years ago
Again:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1237561715.1237568218.22012.gz
Linux mozilla-1.9.1 unit test on 2009/03/20 08:08:35
(Reporter)

Comment 22

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1238088083.1238095807.11266.gz
Linux mozilla-1.9.1 unit test on 2009/03/26 10:21:23

Updated

8 years ago
Assignee: dao → nobody
Whiteboard: [fixed1.9.1b4] [orange] → [orange]
(Reporter)

Comment 23

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238873167.1238878561.18777.gz
Linux comm-central unit test on 2009/04/04 12:26:07
Status: REOPENED → NEW
Flags: wanted1.9.1?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1239029874.1239035833.27679.gz
Linux mozilla-1.9.1 unit test on 2009/04/06 07:57:54

This test is clearly not fixed.
(Assignee)

Comment 25

8 years ago
Created attachment 371534 [details] [diff] [review]
Avoid focus issues
[Checkin: Comment 26]

First chance I've had to look at this again for a while. Sorry, all.

OK, thinking about this again. What triggered 418874 was two or more calls of _updateVisibleText when displaying the emptytext, with only one call to _clearEmptyText. We can actually simulate this without sending keypresses - as the keypresses themselves weren't really relevant, it was the focus()/click() calls that were important.

Simply setting the value of the textbox would work, as changes through the property still end up on the undo stack, and we get the correct sequence of _updateVisible/_clearEmpty calls. With this updated patch, reverting the fix for 418874 causes the last part of the test to fail as expected.
Attachment #371534 - Flags: review?(dao)

Updated

8 years ago
Attachment #371534 - Flags: review?(dao) → review+
(Assignee)

Updated

8 years ago
Keywords: checkin-needed
Would have been interesting to know if that was really a focus issue. I don't see why textbox.focus() would fail if the window had focus. Anyway...

http://hg.mozilla.org/mozilla-central/rev/9a8abc2e3a17
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1f3ebba05fb6
Assignee: nobody → graememcc_firefox
Status: NEW → RESOLVED
Last Resolved: 8 years ago8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
(Reporter)

Updated

8 years ago
Flags: wanted1.9.1? → in-testsuite+
Keywords: fixed1.9.1
Whiteboard: [orange] → [orange] [fixed1.9.1b4]
(Reporter)

Updated

8 years ago
Attachment #371534 - Attachment description: Avoid focus issues → Avoid focus issues [Checkin: Comment 26]

Updated

8 years ago
Depends on: 495751
Comment hidden (Treeherder Robot)
Keywords: intermittent-failure
Whiteboard: [orange] [fixed1.9.1b4] → [fixed1.9.1b4]
You need to log in before you can comment on or make changes to this bug.