Add "fullscreen" button

[Arnei]

Adds "fullscreen" buttons to the videos in the cutting tab.

The goal is to give users a simple way to zoom in on a video in case they need to perceive details, like for example small text on a blackboard.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1585/2025-05-20_13-46-20/ .
It might take a few minutes for it to become available.

[Arnei]

Seems like there are issues with Safari.

[Arnei]

Safari issue should now be fixed.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1585/2025-06-11_08-59-03/ .
It might take a few minutes for it to become available.

[gregorydlogan]

Is this the expected behaviour?

Screencast.from.2025-06-17.22-48-55.mp4

I feel like it's supposed to zoom in more?

[Arnei]

That is not expected behaviour, it should roughly double in size. What browser are you testing with?

[snoesberger]

I did some tests with videos from our test environment and I can confirm the behavior that Greg mentioned (with different browsers: Firefox, Chrome, Safari). Clicking the full-screen button barely enlarges the video. I think this is because the previews generated by the standard workflows are only 360 pixels high. The preview video used by the test deployment (the one with Lars) has a height of 720 pixels; therefore, the full-screen effect is larger with that video.
Ideally, we wouldn't use a fixed factor to resize the video, but rather use the available space. However, I don't know if this is easily feasible?

Additionally, the preview videos used for test.editor.opencast.org should be generated using the same encoding profiles as those used in standard Opencast workflows.

I also found another issue with the thumbnail view. The full-screen button is available there, too, but it doesn't work. And the thumbnail preview is completely broken in Safari:

[github-actions]

This pull request is deployed at test.editor.opencast.org/1585/2026-04-20_12-45-56/ .
It might take a few minutes for it to become available.

[gregorydlogan]

Still seeing the same behaviour I was seeing before the repoint. Testing with Chrome, though I see it in firefox as well.

[ferishili]

Thanks @Arnei!

I tested this on the three major browsers on macOS (Safari 26.4, Firefox 149.0.2, and Chrome 147.0.7727.56), and it works great. ✅

One small improvement that would be nice to add: cursor: pointer; for the new button.

Also, there's an accessibility (A11y) aspect to consider for the new button. I'm not sure yet how far we want to go with that here, but it might be worth taking a quick look and try to introduce it on new elements.

[Arnei]

Hi @ferishili , thanks for testing!

I added cursor: pointer as you suggested. What accessibility aspect are you referring to? Or do you just mean we should generally think about how to make the fullscreen buttons properly accessible?

[ferishili]

Great,
Regarding A11y, I'm not an expert, but for this kind of button an aria-label and an aria-pressed or somthing like that (to indicate whether it's toggled or not) should be sufficient so that screen readers can identify the state properly.

[ferishili]

Nice! Kudos for the awesome icons 👍✨

[gregorydlogan]

I'm still seeing the same behaviour as I was before, regardless of test media. Same behaviour on Chrome and Firefox.

[gregorydlogan]

I'm assuming this moves to 20+

[github-actions]

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.