UV controls scale improperly for audio manifests without ranges
benwbrum opened this issue · comments
UV version: 4.0.22
I'm submitting a:
- bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below
- feature request => please use the user stories repo
- support request => Please do not submit support requests here, use stackoverflow
Current behavior:
When playing a single audio file, users generally want the UV control to be smallish--120-200 pixels high--since there is no video to display and no navigation needed. When loading a IIIF manifest without ranges containing only audio content, the player controls (play, next, volume, etc) scale down to the height of the div, making them appear to be tiny.
Example:
Expected behavior:
The controls should not scale down, but rather appear at the full width of the player.
Steps to reproduce:
Load this manifest in a div sized at 180px: https://saracarl.github.io/comparison-test/her-kind/manifest.json
Related code:
According to discussion on UV Slack, this is caused by some special handling for range-less audio content:
- @stephenwf 3 months ago Ah that's loading the media element extension, which doesn't have a compact-mode like that.
- https://github.com/UniversalViewer/universalviewer/blob/main/src/content-handlers/iiif/IIIFContentHandler.ts#L369-L374
- We could add a config option to skip this step
- @stephenwf 3 months ago https://codesandbox.io/s/uv-config-example-forked-4xjd5q?file=/index.html
- @stephenwf 3 months ago Picking a manifest with a range that uses the AV component does work at around 180px height
Unfortunately, this work-around only works for manifests that contain ranges, so it is not universal.
So just skipping the media element extension, as in @benwbrum's PR above, introduces CORS issues:
Access to video at 'https://ia601606.us.archive.org/0/items/arrival-beginning/ArrivalBeginning.mp4' from origin 'https://lgsump.github.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
(This is true for media at multiple sites, including Internet Archive which usually is wide open.)
We're not sure why. Any ideas?
The CORS issue above appears to be irrelevant.