If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Intermittent test_bug622371.html | The start offset of the selection shouldn't change - got 0, expected 1 | The end offset of the selection shouldn't change - got 0, expected 1

REOPENED
Unassigned

Status

()

Core
Editor
P3
normal
REOPENED
4 years ago
a year ago

People

(Reporter: RyanVM, Unassigned)

Tracking

({intermittent-failure})

Trunk
ARM
Android
intermittent-failure
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [test disabled on Android][leave open])

(Reporter)

Description

4 years ago
Can't help but notice that bug 947170 landed around this time. Retriggering to see if the range can be narrowed down.

https://tbpl.mozilla.org/php/getParsedLog.php?id=32709676&tree=Mozilla-Inbound

Android 2.2 Tegra mozilla-inbound opt test mochitest-7 on 2014-01-08 10:27:16 PST for push d19f386b9061
slave: tegra-321

11289 INFO TEST-START | /tests/editor/libeditor/html/tests/test_bug612447.html
11290 INFO TEST-INFO | /tests/editor/libeditor/html/tests/test_bug612447.html | must wait for load
11291 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | Typing should work
11292 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The editor commands should work
11293 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | Typing should work
11294 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The editor commands should work
11295 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The iframes should look the same before typing
11296 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The iframes should look the same after typing
11297 INFO TEST-INFO | MEMORY STAT vsize after test: 609153024
11298 INFO TEST-INFO | MEMORY STAT residentFast after test: 162463744
11299 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 42375244
11300 INFO TEST-END | /tests/editor/libeditor/html/tests/test_bug612447.html | finished in 608ms
11301 INFO TEST-START | /tests/editor/libeditor/html/tests/test_bug622371.html
11302 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_bug622371.html | The start offset of the selection shouldn't change - got 0, expected 1
11303 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_bug622371.html | The end offset of the selection shouldn't change - got 0, expected 1
11304 INFO TEST-INFO | MEMORY STAT vsize after test: 604463104
11305 INFO TEST-INFO | MEMORY STAT residentFast after test: 155684864
11306 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 34245788
11307 INFO TEST-END | /tests/editor/libeditor/html/tests/test_bug622371.html | finished in 426ms
(Reporter)

Comment 1

4 years ago
https://tbpl.mozilla.org/php/getParsedLog.php?id=32717651&tree=B2g-Inbound
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
(Reporter)

Comment 5

4 years ago
Retriggers are strongly pointing to the landing of bug 940229 as when this started.

Running a backout of that through Try to hopefully confirm.
https://tbpl.mozilla.org/?tree=Try&rev=98dbcdee471d
Blocks: 940229
Flags: needinfo?(dholbert)
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #5)
> Retriggers are strongly pointing to the landing of bug 940229 as when this
> started.

That bug just added a single mochitest, test_extra_inherit_initial.html, and that test is in a completely different batch of mochitests. (This issue is in mochitest-7, whereas test_extra_inherit_initial.html is in mochitest-8. For proof, here's a link to the mochitest-8 log from comment 1's push:
  https://tbpl.mozilla.org/php/getParsedLog.php?id=32717641&tree=B2g-Inbound
)

So I don't see how it's possible that bug 940229 could be responsible, aside from perhaps that it made us reshuffle which existing tests fall into which buckets (as any mochitest-addition would do, IIUC).
Flags: needinfo?(dholbert)
(Reporter)

Comment 7

4 years ago
I've got 30 green runs on the push prior to yours, and yours hit it in 2/10.
(Reporter)

Comment 8

4 years ago
I can also confirm that test_bug622371.html is running in mochitest-7 in that run too.
(In reply to Daniel Holbert [:dholbert] from comment #6)
> That bug just added a single mochitest, test_extra_inherit_initial.html

Technically, bug 940229 also added a few values to some lists in property_database.js.

It's conceivable that these tweaks could've modified the behavior of tests that use property_database.js.  However, libeditor/html/tests/test_bug622371.html doesn't use property_database.js, so that can't be the problem.

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #8)
> I can also confirm that test_bug622371.html is running in mochitest-7 in
> that run too.

Thanks -- I wasn't necessarily suggesting that we shifted test_bug622371.html from one bucket to another, but more that we might've shifted *another* problematic test into (or out of) mochitest-7, and that affected test_bug622371.html's behavior somehow. Seems like a stretch, but it's more conceivable than test_extra_inherit_initial.html (in a different mochitest bucket) affecting test_bug622371.html's behavior.  That's the only conceivable way I could imagine bug 940229 triggering this.
(Reporter)

Comment 10

4 years ago
55 green runs on the push prior and 50 green runs on the Try backout. With our Orange Factor currently sitting around 8, maybe it's best to just backout for now?
Works for me. (Though I'm a bit mystified.)  If the backout fixes it, I can sort it out on Try before re-landing.
Can you look at the list of tests in the logs to see if the landing pushed a test between mochitest sets?  If so, can adding a dummy test elsewhere push it back until further investigation figures out what's up?
Comment hidden (Treeherder Robot)
It looks like dom/tests/mochitest/general/test_clientRects.html was removed from the start of mochitest-7 and js/xpconnect/tests/mochitest/test_bug691059.html was added to the end of mochitest-7.
Though it seems a little more interesting that test_clipboard_events.html is now the first test in the mochitest-7 run whereas it wasn't the first test before.  (Just because that seems slightly more related.)
And, for reference, the tbpl links for the regression range are:
before: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=82cd92e10736
after: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=53aedd08699f
Comment hidden (Treeherder Robot)
Didn't have time to look into Comment 14 tonight, but FWIW:

Here's a Try run with unmodified mozilla-inbound tip as of a few hours ago, with just mochitest-7 and mochitest-8 on Android (it has 12 green M-7 runs on Android-2.2 so far, with more queued... I'm expecting it to hit some instances of this bug eventually):
  https://tbpl.mozilla.org/?tree=Try&rev=a6b6656fc6b7

And (assuming that^ eventually turns orange) here's a Try run with test_extra_inherit_initial.html removed from the mochitest.ini, which would be one possible temporary-workaround for this issue:
  https://tbpl.mozilla.org/?tree=Try&rev=1e156f604946

If the first Try run hits this orange and the second does not, then that'll confirm that it is indeed just the test list modification that caused this.
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #7)
> I've got 30 green runs on the push prior to yours, and yours hit it in 2/10.

Interestingly, the first Try run from comment 18 (unmodified mozilla-inbound, including bug 940229's patches and hence expected-to-be-orange) has now 34 completed M-7 runs on Android-2.2 now, all of them green.

So: it looks like this might have fixed itself, or something.

If we can't make that Try run go orange, then maybe it means this issue only affects builds that were generated during a certain window of time, due to a build toolchain quirk, or an infra change, or something like that... (?)
That first Try run from comment 18 now has 68/68 green M-7 runs. So, it's looking like m-i has been cured of this, somehow.

(BTW: I suspected that maybe this became fixed simply by someone inserting or removing another mochitest, which would potentially have offset the one that I added & rebalanced the mochitest-batches.  That's not the case, though -- at least,  the broken "after" TBPL cycle from comment 16 has the same same starting and ending tests (test_clipboard_events.html - test_bug691059.html) as the (not-broken) first Try run in comment 18.)
So unless we get more reports here, I guess this is WORKSFORME for the time being.

I'll wait a day or so before resolving it. --> setting needinfo=me so I remember.
Flags: needinfo?(dholbert)
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(dholbert)
Comment hidden (Treeherder Robot)
(Reporter)

Updated

4 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
(Reporter)

Comment 26

4 years ago
This test has once again demonstrated its flakiness. Skipping on Android until "someone" can look at it in greater details.

https://hg.mozilla.org/integration/fx-team/rev/c24edbc71fbc
Whiteboard: [test disabled on Android][leave open]
(Reporter)

Comment 27

4 years ago
And because it's been one of *those* weeks, really disable it this time.

https://hg.mozilla.org/integration/fx-team/rev/f5d04ca4795d
No longer blocks: 940229
Depends on: 622371
(Reporter)

Comment 28

4 years ago
https://hg.mozilla.org/mozilla-central/rev/c24edbc71fbc
https://hg.mozilla.org/mozilla-central/rev/f5d04ca4795d

Comment 29

a year ago
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.