Bug 179315 – Content not painted when scrolling an overflow node inside an iframe

• Status: RESOLVED
• Resolution: FIXED
• Component: Frames

[Frédéric Wang (:fredw)]

Created attachment 326110 [details]
Testcase

The attached testcase contains an overflow node inside an iframe. The overflow itself node contains some green rectangle. On iOS 11, the green rectangle is not visible/painted when you scroll the overflow node down. Note that changing a bit the CSS or HTML content may make the green rectangle visible. 

This issue was initially reported in https://github.com/ampproject/amphtml/issues/11829 ; and the testcase was reduced from https://output.jsbin.com/veficav/quiet

[Frédéric Wang (:fredw)]

Per the original github issue, this is a regression as it affects iOS 11, not iOS 10 (I did not verify this assertion though).

[Radar WebKit Bug Importer]

<rdar://problem/35364166>

[Dima Voytenko]

I'm seeing this bug in different combinations quite a bit. It looks like a very large regression.

[Simon Fraser (smfr)]

Are you seeing issues scrolling inside overflow:scroll in UIWebView? If so, that's bug 179315

[Frédéric Wang (:fredw)]

(In reply to Simon Fraser (smfr) from comment #4)
> Are you seeing issues scrolling inside overflow:scroll in UIWebView? If so,
> that's bug 179315

Which bug did you mean to mention?

[Simon Fraser (smfr)]

Sorry, bug 179277.

[Frédéric Wang (:fredw)]

(In reply to Simon Fraser (smfr) from comment #6)
> Sorry, bug 179277.

At least for attachment 326110 [details]  and https://output.jsbin.com/veficav/quiet, your patch does not fix the problem.

[Justin Ridgewell]

I was able to pear down the initial AMP bug report to https://output.jsbin.com/pehorog/28

This produces **without** an iframe, just using any ole document with overflow-scrolling: touch, an div with overflows, and position: relatives.

[Simon Fraser (smfr)]

Are you folks testing in Safari or UIWebView?

[Justin Ridgewell]

Directly in Safari for me.

[Justin Ridgewell]

To be explicit:

"Mozilla/5.0 (iPhone; CPU iPhone OS 11_0_3 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A432 Safari/604.1" on an iPhone SE.

"Mozilla/5.0 (iPhone; CPU iPhone OS 11_0_3 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A432 Safari/604.1" on an iPhone 6.

[Simon Fraser (smfr)]

For me the last line pops in after a delay, but it doesn't look great. Feels similar to   bug 179277.

[Justin Ridgewell]

Ok, the "pops in after a delay" is actually because of the little "Edit in JSBin" button that disappears, causing a recalc. If you haven't scrolled to view the text before it disappears, the text will remain hidden.

Or, You can visit https://jsbin.com/pehorog/28/quiet, which doesn't have the disappearing JSBin button.

I've also tested this in iOS 9.3.4 (iPhone 6) and iOS 10.2.1 (iPhone 5C), and they produce the same hidden text.

[Dima Voytenko]

Agree with Justin, https://jsbin.com/pehorog/28/quiet repros ~100% of the time and doesn't fix itself. Reflow will eventually fix it if that happens. This repro seems very common. Maybe it's worth raising priority?

[Frédéric Wang (:fredw)]

(In reply to Simon Fraser (smfr) from comment #9)
> Are you folks testing in Safari or UIWebView?

Yes, I was testing on Safari too. As I said your fix for the UIWebView did not help, so it's a similar but different regression. I tried bisecting it but it is difficult to build WebKit for iOS 11 on old versions with the public SDK :-( I'll try refining the regression window, but for now:

* Safari 10.2.1 (14D27) ; iOS 10 does not have the bug (according to the original reporter).
* WebKit r220111 (Aug 1) ; iOS 11 has the bug ( https://trac.webkit.org/changeset/220111 ) 

Also, I'm not sure whether the regression is in WebKit or iOS or both.

[Simon Fraser (smfr)]

It's probably a WebKit regression, related to dropping backing store for invisible elements. I'll take a look.

[Simon Fraser (smfr)]

The missing content is in its own compositing layer (because of the position:relative and other composited content z-ordered behind it).

[Justin Ridgewell]

Is there anything AMP can do to avoid this issue? Or, anything we can do to detect/fix it? I was able to hack together a fix by applying transform: translateZ(0) to _anything_ with relative/absolute positioning. But that's super expensive to detect, isn't going to work for every page (position: fixed springs to mind), and (I'd imagine) expensive for Safari to render.

We're very worried this affecting a larger percentage of AMP docs. We frequently get internal communications from publishers with "broken" pages due to GPU issues in iOS. One affected every (!!!) Pinterest page in search.

AMP allows publisher provided CSS on the page, but otherwise controls the entire document from "default" CSS (where we can override anything by using !important) and we're the only JS running on the page. Basically any fix you can think of, we can implement. We're just looking for the right approach.

[Simon Fraser (smfr)]

I'll tell you when I've figured out what causes it.

[Simon Fraser (smfr)]

In the stacking order tree, <h1 class="test"> is a sibling of <div class="card">, and should be painted later. <h1 class="test"> gets composited, so normally <div class="card"> would also get composited because of overlap. However, I think we detect that <div class="card"> is outside the viewport, so don't composite it. The problem is that it gets revealed by overflow scrolling and we don't run the overlap testing logic again.

A simple fix is to make <div class="card"> a stacking context by adding z-index:0

[Simon Fraser (smfr)]

Ah, we don't check for overlap changes on composited scroll, and should

[Simon Fraser (smfr)]

Created attachment 326413 [details]
Patch

[Build Bot]

Comment on attachment 326413 [details]
Patch

Attachment 326413 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/5157137

New failing tests:
http/tests/workers/service/service-worker-clear.html

[Build Bot]

Created attachment 326424 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123  Port: ios-simulator-wk2  Platform: Mac OS X 10.12.6

[WebKit Commit Bot]

Comment on attachment 326413 [details]
Patch

Clearing flags on attachment: 326413

Committed r224618: <https://trac.webkit.org/changeset/224618>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Frédéric Wang (:fredw)]

@Simon: Thanks for your patch. I just tried the two test cases again with a fresh build and I can confirm the bugs are fixed.

[Dima Voytenko]

Thanks so much for the quick turn around!