[Webkit-unassigned] [Bug 217761] REGRESSION: ASSERTION FAILED: !needsLayout() on webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html (flaky)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=217761

Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cdumez at apple.com,
                   |                            |dino at apple.com,
                   |                            |jdarpinian at chromium.org,
                   |                            |kkinnunen at apple.com
            Summary|REGRESSION (r266662?):      |REGRESSION: ASSERTION
                   |ASSERTION FAILED:           |FAILED: !needsLayout() on
                   |!needsLayout() on           |webgl/2.0.0/conformance/ext
                   |webgl/2.0.0/conformance/ext |ensions/webgl-compressed-te
                   |ensions/webgl-compressed-te |xture-s3tc-srgb.html
                   |xture-s3tc-srgb.html        |(flaky)
                   |(flaky)                     |

--- Comment #4 from Alexey Proskuryakov <ap at webkit.org> ---
This one has a complicated history.

I could reproduce starting with r266364, where WEBGL_compressed_texture_s3tc_srgb extension was implemented. This assertion seems unlikely to have anything to do with S3TC or WebGL, it's probably just because the test started to have a long output after the feature got implemented. It's about 15 pages on my screen.

Then this was completely fixed by r266645, Move lazy DisplayLink tear down logic from the WebProcess to the UIProcess.

It became easily reproducible again after r266710, where the above was reverted.

Then r266645 was re-landed in r266797, but the issue was not completely fixed this time. It's still reproducible, but only about once in a 1000 iterations.

So either the new DisplayLink patch is not as effective as the original one, or something happened between r266710 and r266797 that created a new reason for the test to assert.

This is the only test for a feature, so it's pretty important.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201018/01f87a1f/attachment-0001.htm>