UV controls scale improperly for audio manifests without ranges

[benwbrum]

UV version: 4.0.22

I'm submitting a:

• [x] 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.

[saracarl]

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?

[benwbrum]

The CORS issue above appears to be irrelevant.