Bug 148409 – Layout Test platform/mac/fast/events/content-inset-hit-testing-in-frame.html is flaky

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Tim Horton]

The following layout test is flaky on Mac WK1

platform/mac/fast/events/content-inset-hit-testing-in-frame.html

[Tim Horton]

I'm looking at this.

In the bad case, we hit the iframe, but not the div inside it (we hit the body instead).

[Tim Horton]

Hmm. Render tree dumps for each hit test are exactly the same, we just hit a different node...

[Tim Horton]

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".

[Tim Horton]

The hit test *request* point is different (off by the topContentInset):

bad case: 20 120
good case: 20 20

why is that racy, though?

[Tim Horton]

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.

[Tim Horton]

We do a view->windowToContents() (in EventHandler's documentPointForWindowPoint) and are returned a lie.

[Tim Horton]

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.

[Tim Horton]

scrollPositionChangedViaPlatformWidgetImpl is happening too late in the bad case.

[Tim Horton]

(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...

[Tim Horton]

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)

[Tim Horton]

Created attachment 259890 [details]
Patch

[Tim Horton]

This is admittedly pretty icky, and I haven't managed to make a test app to demonstrate the underlying problem.

[Tim Horton]

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.

[Tim Horton]

http://trac.webkit.org/changeset/188971