| Summary: | Layout Test platform/mac/fast/events/content-inset-hit-testing-in-frame.html is flaky | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Tim Horton <thorton> | ||||
| Component: | Tools / Tests | Assignee: | Tim Horton <thorton> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, bdakin, mitz, simon.fraser | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Tim Horton
2015-08-24 18:22:49 PDT
I'm looking at this. In the bad case, we hit the iframe, but not the div inside it (we hit the body instead). Hmm. Render tree dumps for each hit test are exactly the same, we just hit a different node... Reproduces if you reduce your machine to 1 core, load it (with some while(1)s), and "run-webkit-tests -1 --repeat-each=100000 platform/mac/fast/events/content-inset-hit-testing-in-frame.html". The hit test *request* point is different (off by the topContentInset): bad case: 20 120 good case: 20 20 why is that racy, though? setTopContentInset does a layout, and the layout isn't wrong (as evidenced by the render tree dumps being identical)... it's the point mapping that's wrong. I'm not sure where topContentInset gets applied to incoming points, though. Will have to find that. We do a view->windowToContents() (in EventHandler's documentPointForWindowPoint) and are returned a lie. OK! In the bad case, the scrollOffset.y() = 100 (the top content inset). In the good case it's 0 (as it should be). Not sure why it takes time for the scrollOffset to adjust to the TCI change. Will continue investigating. scrollPositionChangedViaPlatformWidgetImpl is happening too late in the bad case. (In reply to comment #8) > scrollPositionChangedViaPlatformWidgetImpl is happening too late in the bad > case. In the good case, we get it underneath the layout that setTopContentInset does (like you'd expect). In the bad case, we get it much later, under [NSView viewWillDraw] stuff... And it looks like this is happening because we have scrollbars forced off until after the test runs (when they should be enabled as soon as we set a top content inset) Created attachment 259890 [details]
Patch
This is admittedly pretty icky, and I haven't managed to make a test app to demonstrate the underlying problem. Comment on attachment 259890 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=259890&action=review > Source/WebKit/mac/WebView/WebDynamicScrollBarsView.mm:629 > + [super setContentInsets:edgeInsets]; Mavericks doesn't have this, need an ifdef. |