[ACE-4248] Not able to preview 'webm' file in FireFox browser which is uploaded in the site document library Created: 21-Sep-15  Updated: 01-Dec-16  Resolved: 16-Oct-15

Status: Closed
Project: Alfresco One Platform
Component/s: Document Library
Affects Version/s: 5.1
Fix Version/s: Community Edition 201510 EA, 5.1

Type: Bug Priority: Blocker
Reporter: Charulatha Ganesh [X] (Inactive) Assignee: Closed Issues
Resolution: Won't Fix Votes: 0
Labels: triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Alfresco Share v5.1-SNAPSHOT (r111453-b320, Aikau 1.0.33, Spring Surf 5.1-SNAPSHOT, Spring WebScripts 5.1.2, Freemarker 2.3.20-alfresco-patched, Yui 2.9.0-alfresco-20141223)
Alfresco Enterprise v5.1.0
(r111470-b231) schema 9009


Attachments: PNG File Not able to play the webm file in FF browser for second time.png     Zip Archive big_buck_bunny_480p.zip     PNG File webm file preview error FF 40.png    
Issue Links:
Cloners
is clone of ACE-4247 Not able to preview 'flv' file in Fir... Closed
Related
relates to ACE-4247 Not able to preview 'flv' file in Fir... Closed
is related to by ACE-4247 Not able to preview 'flv' file in Fir... Closed
Testcase ID:

AONE-2009


 Description   

Steps to reproduce:

Test Browser : FireFox (40)
1. Login as admin user
2. Create any site
3. Upload any 'webm' file into the site document library.
4. Click on the play button on the 'webm' file in the document details page and watch the video until the play stops.
5. Click on the play button for the second time and view the display.

Expected:
The video file should be displayed with play button an able to play the video when the play button is clicked at any time.

Actual:
1. 'No video with supported format and MIME type found' message is displayed when clicked on the play button for second time.
2. Also 'No video with supported format and MIME type found' message is displayed when clicked on the pause button while playing the video at any time and this seems to be inconsistent.

Ref : Screen shot attached



 Comments   
Comment by Charulatha Ganesh [X] (Inactive) [ 22-Sep-15 ]

Hi Corina, I updated the description after trying with FF (40) and still able to reproduce the issue.

Comment by Ray Gauss [X] (Inactive) [ 14-Oct-15 ]

This appears to be due to the Firefox video player sending an invalid range request asking for content beyond the actual length (why it does that, I'm not sure).

Let's say the content length is 1000, Firefox is sending a range header of:

Range: bytes=1005-

which means "give me bytes 1005 to the end", but the content length is only 1000.

In the example above the repository currently sends a response with no content and a Content-Length header with a value of -5 (which is a violation of the range spec) and the Share webscript fails to process it.

The repository should instead return an HTTP status of 416 (Requested range not satisfiable) which presumably the Firefox player would handle better.

Note that this incorrect handling of the invalid range request is likely to exist in previous versions of Alfresco.

Robert Schembri, how far back should the fix go? 4.2? Should this be moved to an MNT issue?

Comment by Robert Schembri [ 16-Oct-15 ]

Hi Ray,
This hasnt been reported by a customer so we should fix it for 5.1 only.

Comment by Ray Gauss [X] (Inactive) [ 16-Oct-15 ]

Committed the fix (and a new unit test) for the invalid range request and the appropriate HTTP status code of 416 is now returned.

In an initial call for the content:

...
Proxy request header: range=bytes=1572864-
...
Response status code: 206
Response header: Accept-Ranges=bytes
Response header: Content-Range=bytes 1572864-39256063/39256064
...

and immediately clicking around in the timeline:

...
Proxy request header: range=bytes=39813120-
...
Response status code: 416
Response header: Accept-Ranges=bytes
Response header: Content-Range="*"
Response header: Content-Length=0

However, Firefox unfortunately doesn't handle this any better than our original webscript failure.

We're now returning the appropriate response so I believe this ends up being a Firefox issue, both in the request for an invalid range and in its handling of that response.

Comment by Charulatha Ganesh [X] (Inactive) [ 20-Oct-15 ]

Closing this issue. Since seems to be a Firefox issue and won't be fixed.

Generated at Fri Jul 10 04:22:30 BST 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.