RESOLVED FIXED 261690
REGRESSION (265004@main): Vimeo video controls rendered larger and without volume slider
https://bugs.webkit.org/show_bug.cgi?id=261690
Summary REGRESSION (265004@main): Vimeo video controls rendered larger and without vo...
Jon
Reported 2023-09-18 11:52:56 PDT
Created attachment 467741 [details] STP screenshot. Safari Tech Preview 178 (earlier versions too) renders the embedded Vimeo video controls without the volume slider and larger than Safari (16.6 (18615.3.12.11.2)) and Chrome. For example, the video on https://www.pointfree.co/episodes/ep250-testing-debugging-macros-part-1 renders slightly differently, with larger controls and no mouseover volume slider on the STP. See the attached screen shots for an example.
Attachments
STP screenshot. (2.33 MB, image/png)
2023-09-18 11:52 PDT, Jon
no flags
Safari screenshot (2.34 MB, image/png)
2023-09-18 11:53 PDT, Jon
no flags
rendering in Safari, firefox, chrome (1.27 MB, image/png)
2023-10-13 07:15 PDT, Karl Dubost
no flags
Safari on top, STP bottom (1.82 MB, image/png)
2023-10-13 07:23 PDT, Jon
no flags
rendering in Safari, firefox, chrome (126.65 KB, image/png)
2023-10-13 07:40 PDT, Karl Dubost
no flags
Jon
Comment 1 2023-09-18 11:53:28 PDT
Created attachment 467742 [details] Safari screenshot
Radar WebKit Bug Importer
Comment 2 2023-09-18 14:00:19 PDT
Karl Dubost
Comment 3 2023-09-19 01:42:28 PDT
The control slider is ``` <div role="slider" class="VolumeControl_module_volumeControl__7dca4d92 volume shared_module_focusable__63d26f6d" tabindex="0" aria-valuenow="1" aria-valuetext="100%" aria-label="Volume (use up/down arrow keys to change)" aria-valuemin="0" aria-valuemax="1" data-volume-control="true" style="display: none;"> <div class="VolumeControl_module_volumeBar__7dca4d92"> <div class="VolumeControl_module_volumeBarFill__7dca4d92" style="height: 100%;"></div> <div class="VolumeControl_module_sliderHandle__7dca4d92" style="bottom: 100%;"></div> </div> </div> ``` It has display: none by default. When moving the mouse over the element it is supposed to remove the display: none to show the slider. If we artificially do it the slider is visible. The event is indeed happening in Safari 16.6 but not in STP 177.
Tim Nguyen (:ntim)
Comment 4 2023-09-19 06:04:00 PDT
Antoine Quint
Comment 5 2023-10-02 05:07:51 PDT
More specifically, this regressed with https://commits.webkit.org/265004@main when Navigator.standalone was enabled on macOS. I expect Vimeo used the availability of this property to determine they were running on iOS and displaying a volume slider would not make sense there since the media volume cannot be controlled at a per-media level.
Karl Dubost
Comment 6 2023-10-02 18:50:27 PDT
This is happening in https://f.vimeocdn.com/p/4.25.8/js/player.js with _n = "MacIntel" === navigator.platform && void 0 !== navigator.standalone, A first attempt at contacting Vimeo has been done on https://github.com/webcompat/web-bugs/issues/127942#issuecomment-1744034303
Karl Dubost
Comment 7 2023-10-02 18:52:09 PDT
we could imagine a Quirk that would disable navigator.standalone on player.js (not the full domain Vimeo.com, because it would unintended consequences).
Jon
Comment 8 2023-10-09 11:10:55 PDT
STP Release 180 (Safari 17.4, WebKit 19618.1.1.2) on Sonoma now renders the floating volume slider, though it's still at the larger size.
Karl Dubost
Comment 9 2023-10-13 04:36:20 PDT
Jon, s it larger? I see there is a kind of magnifier effect but this is happening on chrome too. If I compare side by side I get the exact same behavior in Chrome, Safari and Firefox.
Jon
Comment 10 2023-10-13 07:07:29 PDT
Yes, STP (Release 180 (Safari 17.4, WebKit 19618.1.1.2)) still renders larger than shipping Safari (Version 17.0 (19616.1.27.211.1)) on Sonoma.
Karl Dubost
Comment 11 2023-10-13 07:15:30 PDT
Created attachment 468202 [details] rendering in Safari, firefox, chrome Tested on macOS 14.2 --- Safari Technology Preview 179 19617.1.8.1 Firefox Nightly 120.0a1 12023.10.11 Google Chrome Canary 120.0.6064.0 6064.0
Karl Dubost
Comment 12 2023-10-13 07:19:26 PDT
And same rendering with STP 180.
Jon
Comment 13 2023-10-13 07:23:00 PDT
Created attachment 468203 [details] Safari on top, STP bottom I've stacked them here, Safari on top, STP on bottom. Now, if the Safari rendering is now incorrect, that's fine, it seems to work correctly now anyway.
Karl Dubost
Comment 14 2023-10-13 07:40:29 PDT
Created attachment 468204 [details] rendering in Safari, firefox, chrome And here stacked for me. from top to bottom safari, firefox, chrome. Note that the issue is with Vimeo. Not Safari :) Vimeo was using navigator.standalone as a user agent sniffing mechanism which changed the layout. see https://github.com/webcompat/web-bugs/issues/127942#issuecomment-1744034303 Someone from vimeo commented there. The only way I can reproduce the layout of your screenshot is by doing zoom. Could you try Command + 0 to come back to the default size (just in case).
Jon
Comment 15 2023-10-13 07:47:30 PDT
There's no zoom applied. The Actual Size command is grayed out and Command - + and Command - - properly change both the video viewer and text size. In my screen shots, though cropped out, the text was the same size in both. They're both fully functional.
Karl Dubost
Comment 16 2023-10-20 22:04:51 PDT
1. Going to https://www.pointfree.co/episodes/ep250-testing-debugging-macros-part-1 2. with macOS 14 and Safari STP 180 Results: No difference than other browsers on a MacBook Pro M2. I'm asking other people to try to reproduce. I propose we close this. The slider issue has been solved by Vimeo, which was really a functional issue. And if there is something remaining about the size of the controls. Jon, could you open a bug on https://webcompat.com/ with screenshot and devices/browsers references. Thanks.
Note You need to log in before you can comment on or make changes to this bug.