Safari breaks with overlays and WebGL canvas

[cuberoot]

Expected Behaviour

We should be able to use spectrum-web-components alongside WebGL canvas elements in all modern browsers

Actual Behaviour

Overlays (e.g. dropdown) seem to cause strange buffer flipping behaviour in Safari

Reproduce Scenario (including but not limited to)

Use an overlay next to a 3D canvas

Steps to Reproduce

• browse to https://tender-goodall-47cf7b.netlify.app with Safari
• repeatedly open and close the overlay
• it should stay black 😄

If you want to build/run locally:

• clone https://github.com/cuberoot/swc-safari-bug
• yarn install
• yarn start

Platform and Version

Safari 13.1.1 on Mac

Sample Code that illustrates the problem

https://github.com/cuberoot/swc-safari-bug

Logs taken while reproducing problem

[cuberoot]

This problem seems to have occurred between SWC bundle v0.12 and v0.13. There is an swc-bundle-0.12.0 in the swc-safari-bug project. If you build that branch, everything works.

I am wondering if this has to do with the change to put a shadow DOM onto the body element. It certainly seems to have appeared around when that change went in.

This is a pain point for us because we use WebGL canvas in LrWeb.

[bengfarrell]

There's gotta be some weird nuance, despite your setup being so simple. I have a project that I'm working on that overlays a 2D canvas over a Babylon.js scene with a transparent background. I have a dropdown menu that opens over the stack of canvases. It all works in Safari without the flash. I just upgraded to your bundle version and despite some UI breakage from doing so, it's all good. I also went in and replaced my 2D canvas with your WebGL canvas code and it STILL works without the flash from opening the dropdown.

That said, I still verified the weird issue in your project.

No idea if that helps, but it's definitely weird

[Westbrook]

Well...this is super fun. Looks like you can't ever have a webGL canvas in a slot and append things to the DOM? Gonna going this down one step further and submit an issue to Safari, not that I expect it to get addressed anytime soon 😞

We should be wrapping the dir and testing updates work today, and then I'll bring this to the top of the list next week. There are more "traditional" tab trapping techniques we could apply here, whether we completely switch or we isolate on Safari or whatever we can discuss more when I've got some options together.

Thanks for finding this and getting such a tidy repro to work with!

[cuberoot]

@Westbrook I forgot to put this into the description, but I already filed an issue with Apple: https://feedbackassistant.apple.com/feedback/8559020.

Thanks so much for your help! What a pain this is!!

[Westbrook]

Is it naive to point out that it works in tech preview (at least on Catalina)? 😔 So maybe in like 3 years it'll get merged up to the main release channel...

[cuberoot]

Our pain continues to deepen on this one as we are reimplementing our editor and we keep having to revert to our older controls.

[Westbrook]

Re: Apple Feedback
The issues can't be shared for +1-ing, so anyone with a couple of minutes to create an issues that's effectively a copy/paste of this issue, please do!

Re: a workaround
If we move to this code order (pulled from installed JS):

    startTabTrapping() {
        if (!this.trappingInited) {
            this.initTabTrapping();
            this.trappingInited = true;
        }
        if (!this.canTabTrap) {
            return;
        }
        this.tabTrapper.tabIndex = -1;
        this.overlayHolder.hidden = false;
    }

We would be able to prevent a page that didn't, yet, rely on tab trapping to be able to use the code in our overlays for the near term. We're so close to getting a new version of Safari released that might also fix this issue, but not sure how "current minus 2" translates with Safari in our case 100%.

Notes on Tab Trapping:

• Tab trapping is when you prevent focus from accessing parts of the page while a user should be hyper focused on a specific part of it. Often this element is a modal or a dialog, and managing the content in this way allow for the user (and screen readers) to have a better understanding of the interactions they should be thinking about in the current moment.
• w3c demo: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
• Alternate technique: https://www.npmjs.com/package/@a11y/focus-trap
• We ship tab trapping in <overlay-trigger type="modal"> and the imperative version in Overlay.openOverlay, and I don't think it's used by default in any of our code, yet.

@cuberoot and @adixon-adobe let's chat at the beginning of the week about what works for yall now, what will work longer term, and what sort level of "wait and see what Safari does" we have appetite for here.

[Westbrook]

It looks like this issue is corrected on Safari's end with v14. I've updated my Safari bug with that information and the question as to whether the fix might get ported to late v13 releases. Probably not likely, but never hurts to ask. With the lack of pace in Safari releases, how do teams usually manage version support? Do people wait for the v15 to count "current -2" or till the v14.1 release, often not till the spring? #thanksSafari

[adixon-adobe]

I'd say 2 things on this one. We'd definitely continue supporting 13 & 14 until v15 came out. Particularly with Safari where older OS releases don't always have access to the latest major version a longer timeline of support makes sense. But we also like to avoid totally breaking older versions when possible, and if we get customer reports we try to fix if it's easy. There are also cases (and I think this is one) where we might do something nicer on the latest release. So in this case we might only enable tab trapping on Safari 14.

[Westbrook]

@adixon-adobe and @cuberoot how far from the version that has this issue do we need to get to close this as "won't fix"?

[Westbrook]

With Safari on version 15.3, closing as won't fix.