For some videos in IMDb, if you skip to a time via the progress bar, you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later'

RESOLVED FIXED in Firefox -esr52

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED FIXED
6 months ago
3 months ago

People

(Reporter: Kostas, Assigned: jya)

Tracking

({regression, testcase-wanted})

51 Branch
mozilla55
regression, testcase-wanted
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(platform-rel +, firefox-esr52 fixed, firefox53 wontfix, firefox54+ fixed, firefox55+ fixed)

Details

(Whiteboard: [platform-rel-Amazon][platform-rel-IMDb], URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

6 months ago
For some videos in IMDb if you skip to a time via the progress bar, you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later' every single time.

STR
- in a fresh FF53 x64 profile in win10 x64, open either of these trailer video links:
http://www.imdb.com/video/imdb/vi4030179609?playlistId=tt2390361
http://www.imdb.com/title/tt2017020/videoplayer/vi2897651993
http://www.imdb.com/title/tt2316801/videoplayer/vi2080616217
(these videos)
- as the video starts to play, click anywhere on the progress bar to skip to any time: after a few secs you'll get 'Sorry, an error has occurred while attempting video playback. Please try again later'.
- try to refresh the page (F5 or Ctrl+F5) and repeat: it occurs every single time.
- there's no error in Web Console while this occurs.
- On the other hand, if you just let the video play (i.e.) without skipping) instead, 
then playback completes ok.

Also, this, doesn't occur in Chrome 58, Edge 38 or IE 11.

Comment 1

6 months ago
Created attachment 8861304 [details]
nightly imdb.png

Comment 2

6 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

Hi and thanks for the report!

Following the STR from comment 0, I was able to reproduce the issue on all Firefox channels, using Windows 10, Ubuntu 16.04 LTS and MAC OS X.
On the Nightly channel, there are a couple of warnings displayed on the Web console (please see the attachment).
Status: UNCONFIRMED → NEW
Has STR: --- → yes
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
Component: General → Audio/Video: Playback
Ever confirmed: true
Product: Firefox → Core
Version: 53 Branch → Trunk
(Reporter)

Comment 3

6 months ago
> thanks for the report!
You're welcome!

> On the Nightly channel, there are a couple of warnings displayed on the Web console (please see the attachment).

I was mistaken: these warnings on Web Console appear on FF 53 stable too:
> Media resource hxxp://video-http.media-imdb.com/... could not be decoded.
(It's just that they appear right after the "Sorry, an error has occurred" appears, 
not a few seconds earlier, i.e. when the big yellow circle in the video area still spins, so it missed my attention).
Got tons of errors like:

[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:81623000 dur:42000 dts:81623000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:84960000 dur:42000 dts:84960000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:88547000 dur:42000 dts:88547000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467
[17705] WARNING: Frame incorrectly marked as non-keyframe @ pts:90174000 dur:41000 dts:90174000: file /media/jwwang/DATA/codebase/mozilla-central/firefox/dom/media/fmp4/MP4Demuxer.cpp, line 467

and then the seek promise is rejected with:

$2 = (const mozilla::SeekRejectValue &) @0x7f63d049e6b8: {
  mType = mozilla::MediaData::VIDEO_DATA,
  mError = {
    mCode = NS_ERROR_DOM_MEDIA_END_OF_STREAM,
    mMessage = {
      <nsACString> = {
        <mozilla::detail::nsCStringRepr> = {
          mData = 0x7f640fdb4a54 <gNullChar> "",
          mLength = 0,
          mFlags = 1
        },
        members of nsACString:
        static kMaxCapacity = 2147483637
      }, <No data fields>}
  }
}
Flags: needinfo?(jyavenard)
(Assignee)

Comment 5

6 months ago
sounds similar to bug 1347538, but for MP4...

We attempt to seek, but there's no more keyframe after the seek point. So we reach EOS while seeking.
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
Would it be possible that we can add some test or enhance our current tests?
Priority: -- → P1
(Assignee)

Comment 7

6 months ago
Once again, the issue is about the MDSM not handling EOS when seeking. I can make a workaround (again) in the MP4 demuxer instead, but it will be just that a workaround...

The MDSM should properly handle EOS when seeking and not treat it as error.
Comment hidden (mozreview-request)
(Assignee)

Comment 9

6 months ago
mozreview-review
Comment on attachment 8861739 [details]
Bug 1359058 - handle EOS during seeking.

https://reviewboard.mozilla.org/r/133718/#review136696
Attachment #8861739 - Flags: review?(jyavenard) → review+
Thanks!
(Assignee)

Comment 11

6 months ago
That will prevent the error for being shown.. However seeking will still not work.

I don't see how we could check the stream to properly identify the keyframe without scanning the entire content first.

We could remove the check in MP4TrackDemuxer::Seek the looks for a keyframe... But then we would likely get a decoding error later anyway...

Though, on those particular videos, it works just fine...
Somehow, seeking in http://www.imdb.com/video/imdb/vi4030179609?playlistId=tt2390361 works fine on Chrome. Chrome doesn't seem to scan the whole file to find a key frame since seek is very fast on Chrome.
(Assignee)

Comment 13

6 months ago
yes.. somehow, even when those keyframe aren't ones... they decode well anyway...

need to check what's going on...
(Assignee)

Comment 14

6 months ago
Those are very peculiar files...

For once, the muxing is correct, in that the keyframe flags are properly setup. So prior bug 1300296, seeking would have worked.

however, the H264 binary stream is wrong.
All frames' NAL have the type 1 (Coded slice of a non-IDR picture) and the nal_ref_idc of each NAL unit is set to 1. That's clearly wrong...

We would have to do a much deeper stream analysis to detect IDR frames (and I'm not sure it's even possible inner the NAL).

:cpeterson, do we know anyone inside IMDB to get them to correct their stream?
Blocks: 1300296
Flags: needinfo?(cpeterson)
Keywords: regression
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Comment 17

6 months ago
mozreview-review
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

https://reviewboard.mozilla.org/r/133968/#review136870
Attachment #8861969 - Flags: review?(jyavenard) → review+
status-firefox-esr52: --- → affected
Version: Trunk → 51 Branch
(In reply to Jean-Yves Avenard [:jya] from comment #14)
> :cpeterson, do we know anyone inside IMDB to get them to correct their
> stream?

Yes. I will send email to our Amazon contacts about this bug.
Flags: needinfo?(cpeterson)
platform-rel: --- → ?
Whiteboard: [platform-rel-Amazon][platform-rel-IMDb]
Is this a new regression for 53 or was it also broken in 52?
Keywords: regressionwindow-wanted
(Assignee)

Comment 20

6 months ago
it was also broken in 52...

it is a regression though.

Comment 21

6 months ago
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e3cafd0169033dd876ec06cdd75163aaf921529&tochange=ba7d7fe0ea3cafb1b27e738dfa3697eb3f49dec7

Regressed by: Bug 1300296

Updated

6 months ago
platform-rel: ? → +
(Assignee)

Comment 22

6 months ago
Anthony? can you please review this patch?
Flags: needinfo?(ajones)
(Assignee)

Updated

6 months ago
Attachment #8861970 - Flags: review?(ajones) → review?(gsquelart)

Comment 23

6 months ago
mozreview-review
Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

https://reviewboard.mozilla.org/r/133970/#review139350
Attachment #8861970 - Flags: review?(gsquelart) → review+

Comment 24

6 months ago
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a39a98ffb29b
P1. handle EOS during seeking. r=jya
https://hg.mozilla.org/integration/autoland/rev/fe9ac1176159
P2. Rely on container flags when seeking in plain MP4. r=gerald
Backed out for failing mochitest dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html and T(g4) on Windows:

https://hg.mozilla.org/integration/autoland/rev/833e53da0e82242faa11ab1e672de2cd83fb1979
https://hg.mozilla.org/integration/autoland/rev/895836bd8d07e4086dcd02e5b392dfac8ad8d3e4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=fe9ac117615975149ba6f33a6e68593e0396f863&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=96726620&repo=autoland

14:43:18     INFO - TEST-PASS | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | A valid string reason is expected 
14:43:18     INFO - TEST-PASS | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | Reason cannot be empty 
14:43:18     INFO - Buffered messages finished
14:43:18     INFO - TEST-UNEXPECTED-FAIL | dom/canvas/test/webgl-conf/generated/test_conformance__textures__misc__texture-npot-video.html | Test timed out. 
14:43:18     INFO -     reportError@SimpleTest/TestRunner.js:121:7
14:43:18     INFO -     TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5
14:43:18     INFO -     TestRunner.runTests@SimpleTest/TestRunner.js:380:5
14:43:18     INFO -     RunSet.runtests@SimpleTest/setup.js:194:3
14:43:18     INFO -     RunSet.runall@SimpleTest/setup.js:173:5
14:43:18     INFO -     hookupTests@SimpleTest/setup.js:266:5
14:43:18     INFO - parseTestManifest@http://mochi.test:8888/manifestLibrary.js:36:5
14:43:18     INFO - getTestManifest/req.onload@http://mochi.test:8888/manifestLibrary.js:49:11
14:43:18     INFO - EventHandlerNonNull*getTestManifest@http://mochi.test:8888/manifestLibrary.js:45:3
14:43:18     INFO -     hookup@SimpleTest/setup.js:246:5
14:43:18     INFO - EventHandlerNonNull*@http://mochi.test:8888/tests?autorun=1&closeWhenDone=1&consoleLevel=INFO&hideResultsTable=1&manifestFile=tests.json&dumpOutputDirectory=c%3A%5Cusers%5Ccltbld%5Cappdata%5Clocal%5Ctemp&cleanupCrashes=true:11:1
Flags: needinfo?(jyavenard)
(Assignee)

Comment 26

6 months ago
That makes no sense. 

WebGl is untouched, and it doesn't seek in MP4. 

I get heaps of webgl error on try even without those changes.
Flags: needinfo?(jyavenard)
Regression window provided in comment 21.
Keywords: regressionwindow-wanted
Keywords: testcase-wanted
Flags: needinfo?(ajones)
Too late to fix for 53 but we could likely still take a patch for 54.
status-firefox53: affected → wontfix
tracking-firefox54: --- → +
tracking-firefox55: --- → +
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Comment 31

5 months ago
It looks like IMDB has fixed their videos.. frames are properly tagged now.

Comment 32

5 months ago
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0cf76b87767d
P1. handle EOS during seeking. r=jya
https://hg.mozilla.org/integration/autoland/rev/40d98a26598e
P2. Rely on container flags when seeking in plain MP4. r=gerald
https://hg.mozilla.org/mozilla-central/rev/0cf76b87767d
https://hg.mozilla.org/mozilla-central/rev/40d98a26598e
Status: NEW → RESOLVED
Last Resolved: 5 months ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Please request uplift on this, if you think it's appropriate, when you get a chance.
Flags: needinfo?(jyavenard)
(Assignee)

Comment 35

5 months ago
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

Approval Request Comment
[Feature/Bug causing the regression]:1300296
[User impact if declined]: error when seeking in file
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: difficult to say, apparently, IMDB has fixed their encoding. 
[List of other uplifts needed for the feature/fix]: both P1 and P2 to uplift
[Is the change risky?]: no
[Why is the change risky/not risky?]: partial revert, we do not error anymore, instead we go back to simply reaching the end of the file.
[String changes made/needed]: none
Flags: needinfo?(jyavenard)
Attachment #8861969 - Flags: approval-mozilla-beta?
(In reply to Jean-Yves Avenard [:jya] from comment #35)
> Comment on attachment 8861969 [details]
> Bug 1359058: P1. handle EOS during seeking.
> 
> Approval Request Comment
> [Feature/Bug causing the regression]:1300296
> [User impact if declined]: error when seeking in file
> [Is this code covered by automated tests?]: yes
You mean we have a test case to seek to some point that there is no keyframe after it?

Comment 37

5 months ago
mozreview-review
Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

https://reviewboard.mozilla.org/r/133970/#review148716

::: dom/media/fmp4/MP4Demuxer.cpp:500
(Diff revision 2)
>      MOZ_ASSERT(mQueuedSample->mKeyframe,
>                 "mQueuedSample must be a keyframe");

@jya, 

We'll hit this assertion due to the change in this patch.


MP4TrackDemuxer::GetNextSample() might flip the `smaple->mKeyframe` so that the chcek won't pass.

We can either (1) remove this assertion or (2) remove the logics in MP4TrackDemuxer::GetNextSample() which recheck a sync frame is an IDR frame or not and flips the `sample->mKeyframe` variable.

The 2nd solution also resolves the issue of bug 1366999. WDYT?

Updated

5 months ago
Flags: needinfo?(jyavenard)

Updated

5 months ago
See Also: → bug 1366999
(Assignee)

Comment 38

5 months ago
The file that caused this failure had no IDR NAL at all but the first sample.
Checking that a sample is an actual IDR is required due to all the bad data provided in MSE and all the side issues they cause. so (2) is unacceptable.

Please open a new bug for the assertion.
Flags: needinfo?(jyavenard)
(Assignee)

Comment 39

5 months ago
Above I'm referring to the IMDB files which had all frames marked a P-Frame.
(Assignee)

Updated

5 months ago
Depends on: 1369382

Comment 40

5 months ago
Hi Kostas, could you please verify that this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(rick3162)

Comment 41

5 months ago
Comment on attachment 8861969 [details]
Bug 1359058: P1. handle EOS during seeking.

This is a core scenario, Beta54+
Attachment #8861969 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Updated

5 months ago
Attachment #8861970 - Flags: approval-mozilla-beta+

Comment 42

5 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/f282660d8ecb
https://hg.mozilla.org/releases/mozilla-beta/rev/98a5d4f7bc11
status-firefox54: affected → fixed
(In reply to Jean-Yves Avenard [:jya] from comment #35)
> [Is this code covered by automated tests?]: yes
> [Has the fix been verified in Nightly?]: no
> [Needs manual test from QE? If yes, steps to reproduce]: difficult to say,
> apparently, IMDB has fixed their encoding. 

Setting qe-verify- based on the nature of this bug and the fact that this fix has automated coverage.
Flags: qe-verify-
(Reporter)

Comment 44

5 months ago
(In reply to Ritu Kothari (:ritu) from comment #40)
> Hi Kostas, could you please verify that this issue is fixed as expected on a
> latest Nightly build? Thanks!

Yes, of course: I confirm it's fixed in latest Nightly, 55.0a1 (2017-06-02) (64-bit).
Flags: needinfo?(rick3162)
Is this worth trying to rebase for ESR52?
Flags: needinfo?(jyavenard)
(Assignee)

Comment 46

3 months ago
Created attachment 8889568 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

MozReview-Commit-ID: DPT3t1pi6o1
(Assignee)

Comment 47

3 months ago
Created attachment 8889569 [details] [diff] [review]
P2. Rely on container flags when seeking in plain MP4. r=gerald

This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.

MozReview-Commit-ID: H0gF3FqZsU6
(Assignee)

Comment 48

3 months ago
Created attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

MozReview-Commit-ID: DPT3t1pi6o1
(Assignee)

Comment 49

3 months ago
Created attachment 8889571 [details] [diff] [review]
P2. Rely on container flags when seeking in plain MP4. r=gerald

This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.

MozReview-Commit-ID: H0gF3FqZsU6
(Assignee)

Updated

3 months ago
Attachment #8889568 - Attachment is obsolete: true
Flags: needinfo?(jyavenard)
(Assignee)

Updated

3 months ago
Attachment #8889569 - Attachment is obsolete: true
(Assignee)

Comment 50

3 months ago
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

:jw , the MDSM has changed significantly since 52, so I'm not 100% confident this rebase is all it needs.
Attachment #8889570 - Flags: review?(jwwang)
Let me download ESR52 to refresh the memories.
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

Review of attachment 8889570 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM.
Attachment #8889570 - Flags: review?(jwwang) → review+
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

Based on comment 35, the fact that it impacts a high-traffic site (IMDB), the small size of the patches, and considering we've already shipped this fix in Fx54 with no known regressions, I'm nominating this for ESR52 approval now too.
Attachment #8889570 - Flags: approval-mozilla-esr52?
Comment on attachment 8889570 [details] [diff] [review]
P1. handle EOS during seeking. r=jya

This will impact a known site and has been baked. Let's uplift it to ESR52.3.
Attachment #8889570 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+

Comment 55

3 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-esr52/rev/7ccb26caa02f
https://hg.mozilla.org/releases/mozilla-esr52/rev/a93c1a40f0d8
status-firefox-esr52: affected → fixed
You need to log in before you can comment on or make changes to this bug.