Summary: | REGRESSION: Layout Test scrollbars/overflow-custom-scrollbar-crash.html is flaky | ||
---|---|---|---|
Product: | WebKit | Reporter: | Truitt Savell <tsavell> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | graouts, ryanhaddad, simon.fraser, sroberts, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=198177 https://bugs.webkit.org/show_bug.cgi?id=198178 https://bugs.webkit.org/show_bug.cgi?id=198191 |
Description
Truitt Savell
2019-05-22 10:26:19 PDT
Due to a lack of builds I have a regression range of 245563 — 245594. most of these are cherry picks and can be disregarded I was able to reproduce the failure on a checkout of 245585 but not on 245584. Looks like https://trac.webkit.org/changeset/245585/webkit is the cause of this flakiness. This caught two issues: 1. We consider mouseover to a compatibility mouse event, but it isn't. 2. We still account for the fact that preventDefault() was called during handling of a "pointerdown" event even after the mouse is no longer pressed. (In reply to Antoine Quint from comment #4) > This caught two issues: > > 1. We consider mouseover to a compatibility mouse event, but it isn't. This is tracked by https://bugs.webkit.org/show_bug.cgi?id=198177. (In reply to Antoine Quint from comment #4) > This caught two issues: > > 2. We still account for the fact that preventDefault() was called during > handling of a "pointerdown" event even after the mouse is no longer pressed. This is tracked by https://bugs.webkit.org/show_bug.cgi?id=198178. Out of curiosity, what was the mechanism that made pointerdown-prevent-default.html break a subsequent test? Generally, this is not something that I would expect to happen in DOM event test cases. This is fixed now that the commits for 198177 and 198178 have landed. (In reply to Alexey Proskuryakov from comment #7) > Out of curiosity, what was the mechanism that made > pointerdown-prevent-default.html break a subsequent test? > > Generally, this is not something that I would expect to happen in DOM event > test cases. A flag was set inside WebCore’s PointerCaptureController while handling pointerdown and it was not cleared on pointerup. The next test that runs starts off with the PointerCaptureController in a bad state, just like another interaction within that first test would have been a bad state, which is that the tests I’ve added check. Thank you! Does either of the fixes make it so that the bit gets reset on navigation? Even if a navigation happens between pointerdown and pointerup, we don't want the old pointerdown to affect anything in the new page. I do not see anything navigation related in the fixes. No, (In reply to Alexey Proskuryakov from comment #10) > Thank you! > > Does either of the fixes make it so that the bit gets reset on navigation? > Even if a navigation happens between pointerdown and pointerup, we don't > want the old pointerdown to affect anything in the new page. I do not see > anything navigation related in the fixes. No, the PointerCaptureController is not called into during navigation as far as I know. It's entirely possible that something else does though, but this requires testing. Raised https://bugs.webkit.org/show_bug.cgi?id=198191 to track this. |