New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 646001 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Html Audio Element does not allow to skip forward

Reported by r...@corespring.org, Sep 12 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Example URL:

Steps to reproduce the problem:
1. Upload a mp3 audio file to a webserver
2. Load a html page with an audio element using that audio url, eg. <audio controls><source="some-audio.mp3"/></audio>

3. Press play 
4. Once the audio plays, try clicking into the timeline to skip forward the audio 

What is the expected behavior?
The audio file should play from the position i'm skipping to 

What went wrong?
The audio player goes back to the position it was playing

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 53.0.2785.101 m  Channel: n/a
OS Version: 10
Flash Version: Shockwave Flash 22.0 r0
 
Haven't looked but I'd guess you're not serving the video from a server that supports range requests.
Quite recently I hit the same issue. While Chrome requires this header, according to https://tools.ietf.org/html/rfc7233#section-2.3 or https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.5 this settings seems to be redundant:

An origin server that supports byte-range requests for a given target resource MAY send 'Accept-Ranges: bytes' to indicate what range units are supported. 
A client MAY generate range requests without having received this header field for the resource involved. 

Comment 3 by r...@corespring.org, Sep 13 2016

thanks guys, checking the server now

@jan You had to make the server send "Accept-Ranges: bytes" to make it work?  

Comment 4 by r...@corespring.org, Sep 14 2016

Got it working now. The cloudfront distribution only seems to send the header when the cache is hit.  

The bug can be closed. 
Cc: kavvaru@chromium.org
Status: WontFix (was: Unconfirmed)
Thanks for the update.

Closing this issue as per comment #3.
Please feel free to raise a new issue if you face any issue on chrome further.

Thanks,

Sign in to add a comment