Bug 220892 – REGRESSION (r262237) Safari 14.x shows graphics artifacts when scrolling, using drop-down menus or just moving the mouse

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Chris B]

Created attachment 418225 [details]
Screen shots and videos displaying the described behavior

Hello Everyone

For your information, the following is an aggregated copy of the information that I have entered into the CUBA Platform forum beginning October 2, 2020 at the following address describing a Safari 14.x rendering problem. I was not aware of this WebKit site before, so I am entering my information here for the first time.

https://www.cuba-platform.com/discuss/t/macos-catalina-10-15-7-safari-14-0-graphics-problems/13767

Date: Oct. 2nd 2020
Operating System: macOS Catalina 10.15.7 (19H2)
Browser: Safari 14.0 (15610.1.28.1.9, 15610)
Hardware: iMac (Retina 5K, 27-inch, 2020)
Graphics: AMD Radeon Pro 5700 8 GB
File System: Case-Sensitive Journaled HFS+ (APFS)
Datebase: MySQL 8.0.19
CUBA Platform version: 7.2.8 (7.2.7 was also affected)
CUBA Studio plugin version: 14.0-193
IntelliJ version: CUBA Studio 2019.3
VAADIN version: 8.9.2-3-cuba (https://vaadin.com)

Use Case: Normal local standalone development.

Problem: For your information, after recently upgrading my new iMac (bought in August 2020) to macOS Catalina 10.15.7 (19H2), my CUBA application experiences massive graphics problems, primarily with the VAADIN table components. They continually disappear and reappear, often only half drawn, without any user interaction. And while scrolling, my display is covered with various artifacts; please see the attached images.

Note, that I have run my application on my laptop with the previous macOS version 10.15.6 (19G2021) and Safari 13.1.2 (15609.3.5.1.3) with Intel Iris Pro 1536 MB graphics without any problems.

Date: Nov. 20th 2020

I just upgraded my laptop, that previously did not show this problem behavior, and now I see the same problems as originally reported with my new iMac and Safari 14.0. Here are the system details…

Operating System: macOS Big Sur 11.0.1
Browser: Safari 14.0.1 (16610.2.11.51.8)
Hardware: MacBook Pro (Retina, 15-inch, Mid 2015)
Graphics: Intel Iris Pro 1536 MB
File System: Case-Sensitive Journaled HFS+ (APFS)
Datebase: MySQL 8.0.19
CUBA Platform version: 7.2.10
CUBA Studio plugin version: 14.0-193
IntelliJ version: CUBA Studio 2019.3
VAADIN version: 8.9.2-3-cuba (https://vaadin.com)

Note, that if I keep my session open and stop my application and server in CUBA Studio, scrolling around in my open (but disconnected) session, still shows this problem behavior. I therefore assume that it is a rendering problem within Safari 14.x.x.

Date: Jan. 5th 2021

I just upgraded my iMac today to match my laptop and the behavior is the same. Here are the newest system details…

Operating System: macOS Big Sur 11.0.1
Browser: Safari Version 14.0.2 (16610.3.7.1.9)
Hardware: iMac (Retina 5K, 27-inch, 2020)
Graphics: AMD Radeon Pro 5700 8 GB
File System: Case-Sensitive Journaled HFS+ (APFS)
Datebase: MySQL 8.0.19
CUBA Platform version: 7.2.11
CUBA Studio plugin version: 114.3-193
IntelliJ version: CUBA Studio 2019.3
VAADIN version: 8.9.2-3-cuba (https://vaadin.com)

As noted before, if I keep my session open and stop my application server in CUBA Studio, scrolling around in my open (but disconnected) session, still shows this problem behavior. And it is reproducible with all of the provided themes including helium.

Date: Jan. 23rd 2021

I have recorded two new screen videos displaying this behavior.

I hope that this information can be helpful and that this can be fixed soon. Thanks in advance for your efforts.

Best regards
Chris

[Simon Fraser (smfr)]

We'll need access to a page where this problem can be reproduced in order to debug it.

[Radar WebKit Bug Importer]

<rdar://problem/73538454>

[Chris B]

(In reply to Simon Fraser (smfr) from comment #1)
> We'll need access to a page where this problem can be reproduced in order to
> debug it.

Hello Simon, Thank you for your quick response. Currently I can try and provide you with AnyDesk remote access (https://anydesk.com) to my development environment at home. I can reproduce the problem with an AnyDesk session. Would that be sufficient for you? I live in Switzerland, so depending upon where you are, there may be a considerable time difference; at this moment it is 11:15pm Jan. 23rd. Can you please suggest several timeslots during the next several days that would work for you and I will reserve them for you. Please also indicate how I should contact you to best coordinate this. Thanks in advance. Best regards, Chris

[Simon Fraser (smfr)]

We'd need direct access (ability to load the page ourselves) for debugging.

[Chris B]

My application is not yet live, so I will try and find a way to temporarily host it in a cloud container, so I can provide you with the direct access that you require. This will probably take several days; I will let you know when it's ready. Thanks in advance for your patience.

[Chris B]

(In reply to Simon Fraser (smfr) from comment #4)
> We'd need direct access (ability to load the page ourselves) for debugging.

Hello Simon

I have prepared a rudimentary application so that you can reproduce and analyze this problem. Here are the necessary steps:

1. Open https://webkit-debug.herokuapp.com with Safari 14.x
	Login with the following credentials:

	Username: webkit
	Password: Bug220892

After the login you will see an error in the main screen; this can be ignored.

2. Select the “Interests & Profiles” menu item in the upper lefthand corner; this will display another menu named “Interest Profiles”

3. Select “Interest Profiles”; a new screen within the application will open.

4. Select “Performance” from the “Create Interest Profile” drop-down button at the top of the screen; this will open a new display screen within the application's window. (The contents of this demo screen are only partially complete. Please do not let that irritate you.)

5. In this new screen you may immediately see the tables or other components disappearing and reappearing as you move the mouse across the screen.

6. If nothing happens immediately, then please use the scrollbar to move the contents and try selecting the “Publish for Searching” check-box component at the very bottom of the screen. Scrolling will at some time produce rendering artifacts through the entire screen. Have patience; it will happen.

7. To logout select the same icon at the bottom lefthand side of the application window that is to the right of the “Web Kit” label.


That’s it.

Please let me know when you are finished or require assistance. Good luck!

[Simon Fraser (smfr)]

Thank you, I can reproduce. Please let the test site up for now.

[Chris B]

(In reply to Simon Fraser (smfr) from comment #7)
> Thank you, I can reproduce. Please let the test site up for now.

Thank you for the feedback and your efforts. Heroku shutdown the site automatically due to inactivity but I have restarted it in the meantime. You should now have access again.

[Chris B]

Just for documentation completeness, though I am sure that you are already aware of this, this problem can also be reproduced with Safari Version 14.0.3 (16610.4.3.1.4), which I installed and tested yesterday.

[Chris B]

Question(s)

Do you still require access to my application for testing purposes? If YES, until what date approximately?

Thanks in advance for your feedback. Best regards, Chris

[Simon Fraser (smfr)]

Yes, please keep the site up if you can. I did not yet create a reduction from the content. Would another couple of months be acceptable?

[Chris B]

Yes, I can keep the application active until the end of April.

Please note, that I do not monitor it daily and I have noticed several times that it has gone offline, so please contact me if you are no longer able to login an I will restart it. I'm im Switzerland, so I may not be able to react on the same day due to the time difference. Good luck with your further activities and thanks.

[Chris B]

Hello

Can you please indicate how much longer you require my Heroku site for your debugging/testing activities?

And can you please give me an estimation of when the bug-fix will actually be publicly release?

Without a fix, I cannot release my application with Safari support and this will result in some other more pressing problems.

Thanks in advance for your feedback.

Best regards
Chris

[Chris B]

Hello

Can someone please give me feedback to my questions from 2021-05-06 13:41:15 PDT.

Thanks in advance
Chris

[Simon Fraser (smfr)]

Apologies for not getting back to this; please keep the site up if you can. I cannot say anything about when Safari might ship with a fix for this.

[Simon Fraser (smfr)]

Any chance of bringing the test site back?

[Simon Fraser (smfr)]

Created attachment 432640 [details]
Patch

[Simon Fraser (smfr)]

Compositing backing sharing logic exists to reduce the count of composited layers,
allowing layers that would otherwise get composited to paint into the backing store
of some containing block ancestor (usually a scroller). A "backing sharing sequence"
is a backing-provider layer, and a set of layers contiguous in z-order that can
paint into that shared backing. If a layer becomes composited, it must interrupt
the sequence (because layers later in z-order must render on top).

The bug occurred when a layer became composited between the calls to 
BackingSharingState::updateBeforeDescendantTraversal() and BackingSharingState::updateAfterDescendantTraversal(),
for example because of an indirect reason like overflow positioning. Here's an example
of a "bad" backing-sharing state (C = composited, P = backing provider, p = backing sharing):

S---------C-c-- 2 2 (0,0) width=989 height=1093 [SA 0x28cd23990] (layerID 22) {sc 2} RenderView
S-----------c-- 2 2   + (0,0) width=989 height=8 [SA 0x294ed1630] RenderBlock
--O-------CP--- 2 3     + (20,20) width=500 height=400 [SA 0x294ed16c0] (layerID 27) RenderBlock (positioned)
-----------p-s- 3 3     + (37,30) width=446 height=1188 RenderBlock (positioned)
S-------XxC--s- 2 2     + (0,-200) width=200 height=100 (layerID 28) overflow positioning RenderBlock (positioned)
-----------p-s- 3 3     + (10,210) width=300 height=100 RenderBlock (positioned)
--O------------ 2 2     + (530,20) width=20 height=400 [SA 0x294ed1750] RenderBlock (positioned)
--------------- 2 2     + (0,0) width=20 height=20 RenderBlock (relative positioned)

Here "layerID 28" should have interrupted the sequence, but did not. This left the
subsequent layer dangling, and getting painted via the root layer, hence outside the
scope of the scroller, triggering the painting issues.

The fix is to ensure that BackingSharingState::updateAfterDescendantTraversal() terminates
the backing-sharing sequence if 'layer' is composited, but in a way that doesn't undo cases
where the sharing sequence was established by a descendant layer:

S---------C-c-- 2 2 0x55cd633a8 (0,0) width=989 height=1093 [SA 0x55cd1c510] (layerID 22) {sc 2} RenderView
S-----------c-- 2 2   + 0x55cd634e0 (0,0) width=989 height=364 [SA 0x5650dc7e0] RenderBlock
--O-------Cac-- 2 2     + 0x55cd63618 (28,20) width=324 height=324 [SA 0x5650dc870] (layerID 28) clipping RenderBlock (relative positioned)
-NO-------CP--- 2 3       n 0x55cd63750 (12,12) width=304 height=304 [SA 0x5650dc900] (layerID 27) {sc 3} RenderBlock
-NO----------s- 3 3         n 0x55cd63888 (12,12) width=244 height=106 [SA 0x5650dc990] RenderBlock
-----------p-s- 3 3     + 0x55cd639c0 (22,40) width=200 height=44 RenderBlock (relative positioned)

Here 0x55cd63750 provides backing, but we have to not end the sequence when we pop 0x55cd63750
so that 0x55cd639c0 can share it.

So fix BackingSharingState::updateAfterDescendantTraversal() to end a backing sharing sequence
if the provider was the same as it was at updateBeforeDescendantTraversal(), and the current
layer is composited. Refactor to avoid multiple layer.isComposited() tests.

[Simon Fraser (smfr)]

Created attachment 432968 [details]
Patch

[Simon Fraser (smfr)]

*** Bug 227705 has been marked as a duplicate of this bug. ***

[EWS]

Committed r279636 (239450@main): <https://commits.webkit.org/239450@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 432968 [details].

[Chris B]

Thank you very much for all of your efforts!

For your information, I did not receive any bugzilla emails between March 2nd and yesterday July 6th and therefore was not aware, that you could not login to my Heroku test instance. I have deployed my test case application again in case you would like to make a further verification of your solution. The login credentials are the same.

https://webkit-debug.herokuapp.com with Safari 14.x

Username: webkit
Password: Bug220892

I will leave this instance running until Saturday, July 17th.

Thanks again

[Simon Fraser (smfr)]

I'm getting an error: "ERROR: Could not located the page/file: com/company/webkit/html/main.en.html"

[Chris B]

Sorry, but I did not receive your last comment.

I just deployed my test application again, so please give it another try today. Good luck!

[Simon Fraser (smfr)]

Thanks, I tested the site and the bug seems to be fixed. You can take down the server now.

[Simon Fraser (smfr)]

*** Bug 226532 has been marked as a duplicate of this bug. ***

[Simon Fraser (smfr)]

*** Bug 229390 has been marked as a duplicate of this bug. ***