Dragging the video progress bar causes screen lag only in ios safari

[hanaTsuk1]

Search for duplicate issues

• I already searched, and this issue is not a duplicate.

Issue scope

Usability / User Experience

Describe the bug

Dragging the video progress bar causes the screen to lag, and it takes a few to tens of seconds for the video to continue playing

How to reproduce it

1. ./static-web-server --port 8787 --root ./my-public-dir --host 192.168.1.6 --directory-listing
2. Open the link in ios safari, play the video, and drag the progress bar

Expected behavior

Drag the progress bar and play immediately after a brief load

Complementary information

No response

Build target

i686-pc-windows-msvc

Environment and specs

• static-web-server: v2.27.0
• OS: Windows 11 10.0.22631
• Arch: x64
• Client: safari 17.3.1

Additional context

1. After testing, using Android did not occur this phenomenon
2. Using another server, this phenomenon did not occur

[joseluisq]

Can you please share the SWS trace logs when this problems occur?

[joseluisq]

Another question, is the server running in a Windows machine?

[hanaTsuk1]

Pay attention to the upload speed of the taskbar
From the video, it can be felt that there is a clear interval when Android requests are made. There is no pause during playback, and in the end, they all exit playback

ios

ios.mp4

android

android.mp4

Another question, is the server running in a Windows machine?

yes, open browser on mobile phone

[joseluisq]

I will investigate. In the meantime, did you try to run SWS on a Linux machine?

[hanaTsuk1]

It took some time to connect the phone to WSL2. The situation is the same as Windows

[joseluisq]

It took some time to connect the phone to WSL2. The situation is the same as Windows

Are you running the server in WSL2? If so then this probably could explain why SWS is slow.

Please test all your clients (Android and iOS) with the following server variants:

1. Can you try running SWS in a Windows VM (not WSL2) directly or even better in a native Windows machine?
2. Can you run the SWS x86_64-pc-windows-msvc (AMD64 or ARM64) binary instead of i686-pc-windows-msvc (32-bit)?
3. Can you try to run SWS in a Linux VM (not WSL2) or even better in a native Linux machine?
4. Can you also try SWS with --log-level=error?

Let me know which variant works as expected.

[joseluisq]

Here is a simple test in iOS 17.2 (client) using the latest SWS 2.27.0 which is running in a Windows 11 ARM64 VM (not WSL). As you can see, there are no issues when dragging the video progress bar multiple times. This is also tested in macOS Safari 17.2.1 and the latest Chrome in Android 14 with no issues.

The server configuration is the following:

[general]
host = "0.0.0.0"
port = 8787
root = "C:\\Users\\MyUser\\MyPublicDir"
directory-listing = true

Kapture.2024-03-06.at.00.20.24.mp4

Waiting for your tests in #320 (comment)

[hanaTsuk1]

I have verified points 2 and 4 without any changes, and the virtual machine has not been verified yet
I think it may not be related to the operating environment of SWS. I found an old Safari 14.3 version phone, and SWS can run normally
Now I feel confused. If this is a problem with Safari, why can I use server to play normally on Safari 17.3.1 😫

When I use Safari 14.3, just like how it performs on Android, it won't keep requesting, and the log is as follows

2024-03-06T06:31:00.171375Z DEBUG hyper::proto::h1::io: flushed 131072 bytes
2024-03-06T06:31:00.203921Z DEBUG hyper::server::server::new_svc: connection error: connection closed before message completed

Perhaps we can temporarily put aside this issue🙃

[joseluisq]

Or this could be (maybe) due to how keep_alive_timeout works in Hyper. See hyperium/hyper#2136 (comment)

Perhaps we have to be able to overwrite keep_alive_timeout and try reducing the default keep_alive_timeout value.

I guess this error is directly related to which client is (browser) requesting to the server.