Filed by: wkocher [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=96313321&repo=autoland https://queue.taskcluster.net/v1/task/FhRddxb6SlKrqh1WKPcdMg/runs/0/artifacts/public/logs/live_backing.log https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/FhRddxb6SlKrqh1WKPcdMg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
Is this related to bug 1354641?
See Also: → 1354641
Component: Editor → Spelling checker
Btw, this is basically permafailing on the graphics branch on builds with webrender enabled. I would really like to see it fixed soon if possible. I was trying to bisect it in bug 1362424 but my attempt produced an incorrect result.
I am still figuring out how my patch affects this test. I will update here when I find something. Thanks for letting me know. Keep my ni on the bug.
thanks for looking into this :evelyn, please ask for help if needed, we would love to unblock :kats on the graphics branch as well as the high frequency of failures we see on the other branches.
Whiteboard: [stockwell needswork]
I inserted more logs in reftest-content.js and AsyncSpellCheckTestHelper.jsm and tried to figure out what's happening in the STATE_WAITING_FOR_SPELL_CHECKS phrase. Unfortunately I can't reproduce it on try anymore. :( From the logs above, the only speculation is we didn't observe the "inlineSpellChecker-spellCheck-ended". If so, that might be possible that we keep scheduling spell check even though there is nothing to check. I don't know how this could happen because my patch in bug 1354641 schedules the next round when we get a token that haven't checked. Moreover, the test case doesn't seem to have many words to check, so it should be done in just one round as we guarantee we will at least check 5 words in each round... I will try to reproduce this test failure on my local Linux machine next week (I'm in a biz trip, can't access it now) and use rr to see what happened. @kats, you said it's permafailing on the graphics branch, could you tell me how I can run on that branch and how to enable webrender? Thanks!
The graphics branch gets merged to m-c periodically. Right now you should be able to use m-c and get the same behaviour. To enable webrender you need to set the gfx.webrender.enabled pref to true. Note that in bug 1362424 I disabled the test if webrender is enabled, so really to reproduce locally (or on try) you need to do: - update to recent m-c - modify the reftest.list and remove the skip-if(webrender) annotation on the test - run the test with --setpref gfx.webrender.enabled=true. Note that on try/graphics branch the permafail was only on debug builds with e10s enabled. See https://treeherder.mozilla.org/#/jobs?repo=graphics&tochange=b0adf1e0f7ed8a04a90693fc672277016c40b28b&fromchange=5632c98a00e5eab3f747814dd903cbe8a69c66bf&filter-searchStr=quantum%20debug%20reftest for example
There is a great chance that this is a dupe of bug 1363176, FWIW. It may be easier to fix that and see if this one magically goes away too!
I just figured out the problem and have a patch (part 2) on bug 1354641. I will close this bug if I land the patch there.
no failures since may 11th, the backout https://bugzilla.mozilla.org/show_bug.cgi?id=1363176#c11 seemed to have fixed this.
Whiteboard: [stockwell needswork] → [stockwell fixed:backout]
2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.