Player width sizing incorrect on Safari/WebKit browsers about asciinema-player

[ku1ik]

Interesting 🤔 So I just tried to reproduce on Safari 17.3 and it seems to work fine, just as on FF/Chrome. I suspect that this bug was fixed in Safari 17 (released in Sep, 2023). Last time I successfully reproduced this problem was in early September, so I had Safari 16.x then. This means macOS users won't be affected by the problem for too long (until they update Safari).

iOS is a separate story though.

[ku1ik]

Great sleuthing, this Webkit bug report + patch seems like exactly what we're dealing with here.

Currently the font size is dynamically calculated when the player is resized using % as the unit. I thought maybe changing it to em unit would fix that on Safari 16, but I tested that and unfortunately it hasn't.

Given the fix has been already rolled out for both macOS and iOS/iPadOS I'll probably won't spend more time on looking for a Safari 16 workaround. I'm glad you found that GPU workaround though 👏 , I'll point people to your PR if needed, although I doubt I'll get more open issues about this, the only one I got was #246, and it was before Apple released the fixed versions.

[ku1ik]

Hey @albertchae! Awesome to see asciinema being used by NixOS homepage. Big fan and user of NixOS here 🙌

Thanks for the demo and the reproduction example. This indeed seems to be related to the Webkit issue from #246.

I'll look into that and will try to find a way to either fix or workaround the problem. Will get back to you shortly.

[albertchae]

Hey @albertchae! Awesome to see asciinema being used by NixOS homepage. Big fan and user of NixOS here 🙌

Awesome! @garbas mentioned you were a Nixer. I'm a fan of asciinema as well (and also enjoyed your appearance on https://changelog.com/podcast/561). Thanks for confirming on the PR that using width: 100% was the right decision.

Interesting 🤔 So I just tried to reproduce on Safari 17.3 and it seems to work fine, just as on FF/Chrome. I suspect that this bug was fixed in Safari 17 (released in Sep, 2023). Last time I successfully reproduced this problem was in early September, so I had Safari 16.x then. This means macOS users won't be affected by the problem for too long (until they update Safari).

Wow! I took a quick look at Safari 17 and Webkit release notes and they both mentioned Fixed rendering fractional font sizes. (40829933). Further searching led me to https://bugs.webkit.org/show_bug.cgi?id=46987 and WebKit/WebKit#3795 which seems very much related to this bug.

iOS is a separate story though.

According to https://en.wikipedia.org/wiki/Safari_(web_browser)#Safari_17, this was part of iOS 17. So I guess I ran into this for being a major version behind on both mobile and laptop 😬 . I checked nixos.org on a friend's iPhone on iOS 17 and it looks correct!

That said I did remember this weird hack with forcing GPU rendering that worked on WebKit rendering issues in the past and it seems to somewhat work in this case too. I put up a draft PR with it here NixOS/nixos-homepage#1378, but I want to verify whether we have statistics on what percentage of users are on Safari 16 or older before we merge it.

[ku1ik]

You also have some issue with horizontal position of the play button (<div class="ap-play-button">), which renders too far to the right instead of being centered. This is on Safari (including the latest). I noticed that .ap-player .ap-overlay-start .ap-play-button selector in your CSS is missing the top/right/bottom/left: 0 properties. Inspect .ap-play-button on https://asciinema.org/ to see it's there in the original player CSS. I also noticed that when inspecting the NixOS homepage (on your Netlify build), if I just toggle (disable/re-enable) any of the properties on this element then then play button immediately jumps to the correct position and stays there. This feels like another bug in Webkit. The presence of top/right/bottom/left: 0 (as in the original player CSS) seems to mitigate that.

[albertchae]

Given the fix has been already rolled out for both macOS and iOS/iPadOS I'll probably won't spend more time on looking for a Safari 16 workaround.

Yes I think that makes sense! We can close this issue (and should I open a separate issue for the following play button CSS?)

You also have some issue with horizontal position of the play button (<div class="ap-play-button">), which renders too far to the right instead of being centered. This is on Safari (including the latest).

Hmm very interesting, I did notice that it seemed to be slightly to the right as well but put off investigation while fixing the width issue. Thanks for the insight about the CSS being different from the original on nixos.org

I noticed that .ap-player .ap-overlay-start .ap-play-button selector in your CSS is missing the top/right/bottom/left: 0 properties. Inspect .ap-play-button on https://asciinema.org/ to see it's there in the original player CSS. I also noticed that when inspecting the NixOS homepage (on your Netlify build), if I just toggle (disable/re-enable) any of the properties on this element then then play button immediately jumps to the correct position and stays there. This feels like another bug in Webkit. The presence of top/right/bottom/left: 0 (as in the original player CSS) seems to mitigate that.

I also noticed the weirdness where the button will jump to the correct position depending on what I'm doing in safari devtool...

Looking into the missing top/right/bottom/left: 0, I thought it was related to this warning I see when running npm run astro build

23:25:44 [WARN] [vite]
A PostCSS plugin did not pass the `from` option to `postcss.parse`. This may cause imported assets to be incorrectly transformed. If you've recently added a PostCSS plugin that raised this warning, please contact the package author to fix the issue.

But after further investigation, I believe PostCSS is validly replacing top/right/bottom/left: 0 with inset: 0, which is equivalent according to https://developer.mozilla.org/en-US/docs/Web/CSS/inset.

I also discovered we are applying this hack to .ap-play-button because without it, the button only gets centered vertically and not horizontally (at least in both firefox and safari)

So I read up more on centering with absolute position and found a couple resources explaining this top/right/bottom/left: 0 technique

• https://stackoverflow.com/a/44488046
• https://www.smashingmagazine.com/2013/08/absolute-horizontal-vertical-centering-css/

They seem to rely on a few conditions though, which makes me think the suggestion in https://css-tricks.com/centering-css-complete-guide/ under Both Horizontally & Vertically and Is the element of unknown width and height? is more appealing

.parent {
  position: relative;
}
.child {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

Trying this does seem to work for me in both Firefox/Safari. Do you think this might be a change worth making to https://github.com/asciinema/asciinema-player/blob/develop/src/less/partials/_overlays.less ? It looks like if I apply it to .ap-overlay .ap-overlay-start and remove the top/right/bottom/left: 0 on both .ap-overlay .ap-overlay-start and .ap-player .ap-overlay-start .ap-play-button, it centers properly

[ku1ik]

Thanks for looking into this and suggesting an alternative for the centering problem. I don't see why not to use your snippet in the overlay CSS. I'll give it a go, do some testing and hopefully release a new version soon. Thanks!