Closed
Bug 1443424
Opened 6 years ago
Closed 6 years ago
Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application crashed [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]
Categories
(Core :: Panning and Zooming, defect, P2)
Core
Panning and Zooming
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox59 | --- | unaffected |
firefox60 | - | wontfix |
firefox61 | + | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: botond)
References
Details
(Keywords: crash, intermittent-failure)
Crash Data
Attachments
(2 files)
4.31 KB,
patch
|
Details | Diff | Splinter Review | |
59 bytes,
text/x-review-board-request
|
kats
:
review+
|
Details |
Filed by: ncsoregi [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=166106045&repo=autoland https://queue.taskcluster.net/v1/task/IZ_ydxeWQKG_LYYfJ7Db8g/runs/0/artifacts/public/logs/live_backing.log [task 2018-03-05T23:58:54.208Z] 23:58:54 INFO - Buffered messages finished [task 2018-03-05T23:58:54.209Z] 23:58:54 ERROR - TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application terminated with exit code 11 [task 2018-03-05T23:58:54.210Z] 23:58:54 INFO - runtests.py | Application ran for: 0:00:28.356802 [task 2018-03-05T23:58:54.210Z] 23:58:54 INFO - zombiecheck | Reading PID log: /tmp/tmpAgmASspidlog [task 2018-03-05T23:58:54.211Z] 23:58:54 INFO - ==> process 5271 launched child process 5293 [task 2018-03-05T23:58:54.211Z] 23:58:54 INFO - ==> process 5271 launched child process 5326 [task 2018-03-05T23:58:54.212Z] 23:58:54 INFO - ==> process 5271 launched child process 5365 [task 2018-03-05T23:58:54.212Z] 23:58:54 INFO - zombiecheck | Checking for orphan process with PID: 5293 [task 2018-03-05T23:58:54.213Z] 23:58:54 INFO - zombiecheck | Checking for orphan process with PID: 5326 [task 2018-03-05T23:58:54.214Z] 23:58:54 INFO - zombiecheck | Checking for orphan process with PID: 5365 [task 2018-03-05T23:58:54.214Z] 23:58:54 INFO - mozcrash Downloading symbols from: https://queue.taskcluster.net/v1/task/N3DNCH1gRge5Sy6uiNWbVg/artifacts/public/build/target.crashreporter-symbols.zip [task 2018-03-05T23:59:00.458Z] 23:59:00 INFO - mozcrash Copy/paste: /usr/local/bin/linux64-minidump_stackwalk /tmp/tmpVYmX3D.mozrunner/minidumps/1f94962f-77dc-ecad-b447-5678d8ea3116.dmp /tmp/tmpa0f9EC [task 2018-03-05T23:59:08.867Z] 23:59:08 INFO - mozcrash Saved minidump as /builds/worker/workspace/build/blobber_upload_dir/1f94962f-77dc-ecad-b447-5678d8ea3116.dmp [task 2018-03-05T23:59:08.869Z] 23:59:08 INFO - mozcrash Saved app info as /builds/worker/workspace/build/blobber_upload_dir/1f94962f-77dc-ecad-b447-5678d8ea3116.extra [task 2018-03-05T23:59:08.936Z] 23:59:08 INFO - PROCESS-CRASH | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application crashed [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]
Comment 1•6 years ago
|
||
The line of the crashes matches the MOZ_DIAGNOSTIC_ASSERT added in bug 1437694.
Blocks: 1437694
Comment hidden (Intermittent Failures Robot) |
Comment 3•6 years ago
|
||
Let's wait and see if bug 1443518 fixes this. If not then we'll need to investigate.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•6 years ago
|
Severity: normal → critical
Crash Signature: [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]
Keywords: crash
Summary: Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application terminated with exit code 11 → Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application crashed [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]
Comment 7•6 years ago
|
||
This is still happening with some frequency -- #6 Windows topcrash in Nightly 20180406103336, and #7 in Nightly 20180406220121. kats, any ideas?
Flags: needinfo?(bugmail)
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Nicholas Nethercote [:njn] from comment #7) > This is still happening with some frequency -- #6 Windows topcrash in > Nightly 20180406103336, and #7 in Nightly 20180406220121. > > kats, any ideas? See bug 1447131 comment 34 for some background info. If we get some STR for crashes in newer builds (post-bug 1447131 being fixed), we can track down the remaining issue(s) that are causing this.
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(bugmail)
Comment hidden (Intermittent Failures Robot) |
Comment 10•6 years ago
|
||
I just hit this crash when dragging the horizontal scrollbar on https://github.com/opcm/pcm/blob/master/LINUX_HOWTO.txt . I can't reproduce it. https://crash-stats.mozilla.com/report/index/893f02f6-03e8-49e8-8eac-a0a820180411
Comment 11•6 years ago
|
||
Oh, actually, I *was* able to reproduce it just now.
Updated•6 years ago
|
status-firefox59:
--- → unaffected
status-firefox60:
--- → affected
status-firefox61:
--- → affected
status-firefox-esr52:
--- → unaffected
tracking-firefox60:
--- → +
tracking-firefox61:
--- → +
Comment 12•6 years ago
|
||
This is hitting a diagnostic assert, so only DevEdition users are hitting it on 60 (and release users won't). No need to track.
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 14•6 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #10) > I just hit this crash when dragging the horizontal scrollbar on > https://github.com/opcm/pcm/blob/master/LINUX_HOWTO.txt . I can't reproduce > it. > https://crash-stats.mozilla.com/report/index/893f02f6-03e8-49e8-8eac- > a0a820180411 We found reliable STR for reproing this on a Mac: 1. Load the page. Do not scroll the subframe, to avoid layerizing it. 2. Move the mouse over the subframe. 3. Touch the touchpad with two fingers, to cause the subframe's overlay scrollbars to appear, while still being careful not to scroll to subframe. 4. Move the mouse over the overlay scrollbar and click.
Assignee | ||
Comment 16•6 years ago
|
||
This patch is a hack to allow the bug to be triggered on Linux. It basically force-enabled overlay scrollbars on Linux, and adds a way to trigger showing the scrollbars without layerizing the scroll frame (like you can on Mac by putting two fingers on the touchpad; here, I made the trigger be clicking on the scrollframe's contents). Linux STR with this patch: 1. Apply this patch. 2. Load the page. Do not click or scroll the subframe. 3. Position the mouse over the subframe and click once. The subframe's scrollbar should appear. 4. Move the mouse over the subframe scrollbar and click again. Being able to repro this on Linux puts me in a position to debug and fix the underlying issue.
Assignee: nobody → botond
Assignee | ||
Comment 17•6 years ago
|
||
Oh, forgot to mention: WebRender needs to be enabled for the bug to repro (on either Mac or Linux), suggesting that the issue is in WebRender hit testing.
Assignee | ||
Comment 18•6 years ago
|
||
diagnosis |
The problem appears to be that an invariant that WebRender hit testing relies on for correctness, is not being met for scrollbar thumbs. The invariant is that if WebRenderAPI::HitTest() returns a particular (scrollId, hitInfo) pair, then the WebRenderScrollData tree (which generates the hit test tree) contains a "corresponding" node (where that means either a scrollable node that matches scrollId, or if hitInfo contains scrollbar flags, then a scrollbar node with matching scrollbar flags and whose target matches scrollId). For scrollbar nodes in particular, this means that if a CompositorHitTestInfo display item is created with scrollbar flags, the corresponding scrollbar component needs to be "layerized" (meaning, an nsDisplayOwnLayer display item built for it, which will then generate a WebRenderLayerScrollData node). This invariant is being violated by the code in nsIFrame::GetCompositorHitTestInfo() that sets the eScrollbarThumb flag [1]. This code can run even if the thumb is not layerized, since it only checks for the display list builder having "scrollbar flags" and the frame being for a thumb element; scrollbar flags are set in AppendScrollPartsTo() (e.g. [2]) regardless of whether the thumb is layerized. However, the thumb only gets an nsDisplayOwnLayer item if it's being layerized [3]. As a result, we create a CompositorHitTestInfo display item for the thumb frame that has the eScrollbarThumb flag set, but it picks up the wrong scroll target [4] (since the display list builder's current scrollbar target is only set if we're layerizing the thumb). On the compositor side, that then gets matched to the wrong scrollbar node (that of the enclosing scroll frame). For completeness, I also investigated why this issue is specific to WebRender, and specific to overlay scrollbars: - Without WebRender, we perform hit testing on the Layer tree, so there is no mismatch between what we hit test on, and what is present in APZ's hit testing tree, because they are based on the same thing. - With regular (non-overlay) scrollbars, we don't layerize the scrollbar track either [5], which gets us into this branch [6] in GetCompositorHitTestInfo(), which causes the hit result to contain the DTC flag. In such cases APZ does not treat the hit test target as "confirmed", and the diagnostic assert (which tests for a mismatch between a _confirmed_ compositor target and the main-thread target) does not fire. The fix is straightforward: only set the eScrollbarThumb flag on the CompositorHitTestInfo item if the thumb is being layerized, thereby obeying the invariant. [1] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/layout/generic/nsFrame.cpp#11345 [2] https://searchfox.org/mozilla-central/rev/a30a60eadcff99d2a043241955d215dbeccad876/layout/generic/nsGfxScrollFrame.cpp#3149 [3] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/layout/xul/nsSliderFrame.cpp#382 [4] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/layout/painting/nsDisplayList.cpp#5027 [5] https://searchfox.org/mozilla-central/rev/a30a60eadcff99d2a043241955d215dbeccad876/layout/generic/nsGfxScrollFrame.cpp#3178 [6] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/layout/generic/nsFrame.cpp#11302
Comment hidden (mozreview-request) |
Assignee | ||
Comment 20•6 years ago
|
||
I didn't write a test because I don't think we have infrastructure to test overlay scrollbars.
Comment 21•6 years ago
|
||
mozreview-review |
Comment on attachment 8968688 [details] Bug 1443424 - Only set eScrollbarThumb on a CompositorHitTestInfo item if the thumb is being layerized. https://reviewboard.mozilla.org/r/237366/#review243302 Thanks for the detailed explanation! I'm wondering though, if we're not setting the eScrollbarThumb flag for the thumb's hit-test info, might we still want to set the DTC flag on it? Thumbs have "special behaviour" and presumably without the eScrollbarThumb flag APZ might treat the thumb as a regular scrollframe content and not do any applicable "special behaviour".
Attachment #8968688 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 22•6 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #21) > I'm wondering though, if we're not > setting the eScrollbarThumb flag for the thumb's hit-test info, might we > still want to set the DTC flag on it? Thumbs have "special behaviour" and > presumably without the eScrollbarThumb flag APZ might treat the thumb as a > regular scrollframe content and not do any applicable "special behaviour". We still set the eScrollbar flag [1], so it won't be treated as regular scrollframe content. I would expect adding eDispatchToContent to make no difference, because APZ already treats hits on non-thumb scrollbar areas as disptach-to-content (because hitting a scrollbar causes us to set targetConfirmed=false [2], and the async confirmation codepath is only entered for thumbs [3]). That said, I don't think adding eDispatchToContent would harm, either, and may be good future-proofing against future APZ changes. [1] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/layout/generic/nsFrame.cpp#11356 [2] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/gfx/layers/apz/src/APZCTreeManager.cpp#1221 [3] https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/gfx/layers/apz/src/APZCTreeManager.cpp#1228
Comment 23•6 years ago
|
||
Ok, that makes sense. Feel free to land the patch as-is, or add the DTC flag if you want. I don't feel strongly either way.
Comment hidden (mozreview-request) |
Assignee | ||
Comment 25•6 years ago
|
||
I ended up adding the DTC flag.
Comment 26•6 years ago
|
||
Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a10d637e1678 Only set eScrollbarThumb on a CompositorHitTestInfo item if the thumb is being layerized. r=kats
Comment 27•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a10d637e1678
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Comment hidden (Intermittent Failures Robot) |
Comment 29•6 years ago
|
||
Looks like there's still crash reports coming in on Nightly builds including this patch? Lower in volume, though.
Flags: needinfo?(botond)
Assignee | ||
Comment 30•6 years ago
|
||
I don't really have much to add to what I said in bug 1447131 comment 34: several underlying bugs can cause this symptom, and while we fixed one here, there are others. (This time, it's not even surprising that there are others, because the issue fixed here affected Mac overlay scrollbars only, while the crashes occur on other platforms too.) If we can get STR for a remaining instance of the crash, I'm happy to investigate further. (And, as a reminder, this "crash" is a diagnostic assert that will not fire on release, and therefore I don't believe needs to be tracked.)
Flags: needinfo?(botond)
Updated•6 years ago
|
Comment hidden (Intermittent Failures Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•