Bug 167830

Summary:

WebContent process repeatedly jetsams on BuzzFeed's Another Round page

Product:

WebKit

Reporter:

Ryosuke Niwa <rniwa>

Component:

Layout and Rendering

Assignee:

Ryosuke Niwa <rniwa>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bfulgham, commit-queue, esprehn+autocc, glenn, kling, kondapallykalyan, simon.fraser, thorton, zalan

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

URL:

https://www.buzzfeed.com/anotherround

See Also:

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

Attachments:

Description	Flags
Fixes the bug	none
Test case (attempt; doesn't work)	none
Fixes the bug	none
Archive of layout-test-results from ews122 for ios-simulator-wk2	none
Patch for landing	buildbot: commit-queue-
Archive of layout-test-results from ews122 for ios-simulator-wk2	none

Ryosuke Niwa

Reported 2017-02-03 21:04:12 PST

Visit https://www.buzzfeed.com/anotherround on iOS. It always jetsams :(

Attachments
Fixes the bug (2.91 KB, patch) 2017-02-03 21:13 PST, Ryosuke Niwa	no flags	Details Formatted Diff Diff
Test case (attempt; doesn't work) (1.75 KB, text/html) 2017-02-06 22:27 PST, Ryosuke Niwa	no flags	Details
Fixes the bug (1.95 KB, patch) 2017-02-06 22:35 PST, Ryosuke Niwa	no flags	Details Formatted Diff Diff
Archive of layout-test-results from ews122 for ios-simulator-wk2 (935.61 KB, application/zip) 2017-02-07 02:27 PST, Build Bot	no flags	Details
Patch for landing (1.81 KB, patch) 2017-02-07 13:44 PST, Ryosuke Niwa	buildbot: commit-queue-	Details Formatted Diff Diff
Archive of layout-test-results from ews122 for ios-simulator-wk2 (793.63 KB, application/zip) 2017-02-07 15:00 PST, Build Bot	no flags	Details
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.

Ryosuke Niwa

Comment 1 2017-02-03 21:04:30 PST

<rdar://problem/30187368>

Ryosuke Niwa

Comment 2 2017-02-03 21:13:20 PST

Created attachment 300600 [details] Fixes the bug

Ryosuke Niwa

Comment 3 2017-02-03 21:13:44 PST

I don't know this code can be tested. Any advice will be appreciated.

WebKit Commit Bot

Comment 4 2017-02-03 21:16:33 PST

Attachment 300600 [details] did not pass style-queue: ERROR: Source/WebCore/rendering/RenderLayerCompositor.cpp:2760: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.

Simon Fraser (smfr)

Comment 5 2017-02-03 21:35:50 PST

Comment on attachment 300600 [details] Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=300600&action=review Did you test whether scrolling iframes with position:fixed content works on Mac with this change? I suspect you'll get bad repaints because FrameView::useSlowRepaints isn't set up to handle non-composited fixed in WK2. > Source/WebCore/rendering/RenderLayerCompositor.cpp:2758 > + RELEASE_LOG(Compositing, "Layer = %p layerBounds (x=%f, y=%f, w=%f, h=%f) viewBounds (x=%f, y=%f, w=%f, h=%f)", &layer, > + layerBounds.x().toFloat(), layerBounds.y().toFloat(), layerBounds.width().toFloat(), layerBounds.height().toFloat(), > + viewBounds.x().toFloat(), viewBounds.y().toFloat(), viewBounds.width().toFloat(), viewBounds.height().toFloat()); I don't think you want this logging in release.

Simon Fraser (smfr)

Comment 6 2017-02-03 21:36:38 PST

(In reply to comment #3) > I don't know this code can be tested. Any advice will be appreciated. Yes, you can dump the layer tree (see layerTreeAsText).

Ryosuke Niwa

Comment 7 2017-02-04 01:06:07 PST

(In reply to comment #5) > Comment on attachment 300600 [details] > Fixes the bug > > View in context: > https://bugs.webkit.org/attachment.cgi?id=300600&action=review > > Did you test whether scrolling iframes with position:fixed content works on > Mac with this change? I suspect you'll get bad repaints because > FrameView::useSlowRepaints isn't set up to handle non-composited fixed in > WK2. It looks like this is working just fine. I'll add a test anyway. Now I realize that we probably want to do this only on the layer of the flattened iframe, and but not on a random stuff inside another scrollable element inside any iframe. > > Source/WebCore/rendering/RenderLayerCompositor.cpp:2758 > > + RELEASE_LOG(Compositing, "Layer = %p layerBounds (x=%f, y=%f, w=%f, h=%f) viewBounds (x=%f, y=%f, w=%f, h=%f)", &layer, > > + layerBounds.x().toFloat(), layerBounds.y().toFloat(), layerBounds.width().toFloat(), layerBounds.height().toFloat(), > > + viewBounds.x().toFloat(), viewBounds.y().toFloat(), viewBounds.width().toFloat(), viewBounds.height().toFloat()); > > I don't think you want this logging in release. Oops, removed.

Ryosuke Niwa

Comment 8 2017-02-04 01:09:29 PST

Ugh... that doesn't quite work :(

Ryosuke Niwa

Comment 9 2017-02-06 21:54:39 PST

It looks like we can't test this change without modifying layerTreeAsText or adding a new flag :( There's no difference in layerTreeAsText regardless of which existing flag I use.

Ryosuke Niwa

Comment 10 2017-02-06 22:27:07 PST

In fact, LAYER_TREE_INCLUDES_TILE_CACHES is just as useless. Somehow WTR/DRT claims the tile doesn't exit when running the test even though I can see the tile getting created on the device :(

Ryosuke Niwa

Comment 11 2017-02-06 22:27:27 PST

Created attachment 300790 [details] Test case (attempt; doesn't work)

Ryosuke Niwa

Comment 12 2017-02-06 22:35:31 PST

Created attachment 300791 [details] Fixes the bug

Simon Fraser (smfr)

Comment 13 2017-02-06 22:44:39 PST

LAYER_TREE_INCLUDES_TILE_CACHES dumps TiledBacking data, which only kicks in when layers get large (over 2K on a side). Did the commit that added the "backing store attached" logic add any tests?

Simon Fraser (smfr)

Comment 14 2017-02-06 22:45:59 PST

Comment on attachment 300791 [details] Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=300791&action=review > Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:383 > + // Force the coverage rect to be updated since setVisibleAndCoverageRects exits early when intersectsCoverageRect didn't change. I don't think the comment is necessary, actually. It's easy to deduce why CoverageRectChanged needs to be set when looking at the code, and this means it could go in the initializer.

Build Bot

Comment 15 2017-02-07 02:27:17 PST

Comment on attachment 300791 [details] Fixes the bug Attachment 300791 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3018585 New failing tests: compositing/masks/solid-color-masked.html pageoverlay/overlay-remove-reinsert-view.html

Build Bot

Comment 16 2017-02-07 02:27:21 PST

Created attachment 300798 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6

Ryosuke Niwa

Comment 17 2017-02-07 13:32:43 PST

Hm... these test failures look related to my change but I can't reproduce them locally.

Ryosuke Niwa

Comment 18 2017-02-07 13:44:07 PST

Created attachment 300847 [details] Patch for landing

Ryosuke Niwa

Comment 19 2017-02-07 13:44:45 PST

Comment on attachment 300847 [details] Patch for landing Let's wait for EWS again and see if the test failure persists.

Ryosuke Niwa

Comment 20 2017-02-07 14:50:00 PST

Oh, I don't have that overlay test :( Updating the checkout...

Build Bot

Comment 21 2017-02-07 15:00:02 PST

Comment on attachment 300847 [details] Patch for landing Attachment 300847 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3021668 New failing tests: pageoverlay/overlay-remove-reinsert-view.html

Build Bot

Comment 22 2017-02-07 15:00:06 PST

Created attachment 300853 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6

Ryosuke Niwa

Comment 23 2017-02-07 16:58:35 PST

Okay, I'm rebaselining the test after talking with Simon. This test is kind of testing my fix I suppose. It's still sad that we can't directly test this case.

Ryosuke Niwa

Comment 24 2017-02-07 16:59:33 PST

Committed r211845: <http://trac.webkit.org/changeset/211845>

Brent Fulgham

Comment 25 2017-02-21 09:25:30 PST

(In reply to comment #3) > I don't know this code can be tested. Any advice will be appreciated. It turns out this broke Windows pretty significantly. I'm investigating why.

Simon Fraser (smfr)

Comment 26 2017-02-21 09:53:16 PST

It looks like Per already did: bug 168654

Note You need to log in before you can comment on or make changes to this bug.