1359058 - 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'

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Kostas]

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

[Carmen Fat [:cfat] - Ecosystem QA]

Attachment: nightly imdb.png

Comment 2

[Carmen Fat [:cfat] - Ecosystem QA]

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).

Comment 3

[Kostas]

> 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).

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

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>}
  }
}

Comment 5

[Jean-Yves Avenard [:jya]]

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.

Comment 6

[Blake Wu [:bwu][:blakewu]]

Would it be possible that we can add some test or enhance our current tests?

Comment 7

[Jean-Yves Avenard [:jya]]

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 8

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1359058 - handle EOS during seeking.

Review commit: https://reviewboard.mozilla.org/r/133718/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/133718/

Comment 9

[Jean-Yves Avenard [:jya]]

Comment on attachment 8861739 [details]
Bug 1359058 - handle EOS during seeking.

https://reviewboard.mozilla.org/r/133718/#review136696

Comment 10

[JW Wang [:jwwang] [:jw_wang]]

Thanks!

Comment 11

[Jean-Yves Avenard [:jya]]

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...

Comment 12

[JW Wang [:jwwang] [:jw_wang]]

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.

Comment 13

[Jean-Yves Avenard [:jya]]

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

need to check what's going on...

Comment 14

[Jean-Yves Avenard [:jya]]

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?

Comment 15

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1359058: P1. handle EOS during seeking.

Review commit: https://reviewboard.mozilla.org/r/133968/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/133968/

Comment 16

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

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.

Review commit: https://reviewboard.mozilla.org/r/133970/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/133970/

Comment 17

[Jean-Yves Avenard [:jya]]

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

https://reviewboard.mozilla.org/r/133968/#review136870

Comment 18

[Chris Peterson [:cpeterson]]

(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.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Is this a new regression for 53 or was it also broken in 52?

Comment 20

[Jean-Yves Avenard [:jya]]

it was also broken in 52...

it is a regression though.

Comment 21

[Alice0775 White]

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

Regressed by: Bug 1300296

Comment 22

[Jean-Yves Avenard [:jya]]

Anthony? can you please review this patch?

Comment 23

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

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

Comment 24

[Pulsebot]

Pushed by [e-mail]:
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

Comment 25

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 26

[Jean-Yves Avenard [:jya]]

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.

Comment 27

[Justin [:JW_SoftvisionQA]]

Regression window provided in comment 21.

Comment 28

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix for 53 but we could likely still take a patch for 54.

Comment 29

[Jean-Yves Avenard [:jya]]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/133968/diff/1-2/

Comment 30

[Jean-Yves Avenard [:jya]]

Comment on attachment 8861970 [details]
Bug 1359058: P2. Rely on container flags when seeking in plain MP4.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/133970/diff/1-2/

Comment 31

[Jean-Yves Avenard [:jya]]

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

Comment 32

[Pulsebot]

Pushed by [e-mail]:
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

Comment 33

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/0cf76b87767d
https://hg.mozilla.org/mozilla-central/rev/40d98a26598e

Comment 34

[Nathan Froyd [:froydnj]]

Please request uplift on this, if you think it's appropriate, when you get a chance.

Comment 35

[Jean-Yves Avenard [:jya]]

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

Comment 36

[Blake Wu [:bwu][:blakewu]]

(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

[Tzuhao Kuo [:kaku]]

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?

Comment 38

[Jean-Yves Avenard [:jya]]

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.

Comment 39

[Jean-Yves Avenard [:jya]]

Above I'm referring to the IMDB files which had all frames marked a P-Frame.

Comment 40

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Kostas, could you please verify that this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 41

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

This is a core scenario, Beta54+

Comment 42

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f282660d8ecb
https://hg.mozilla.org/releases/mozilla-beta/rev/98a5d4f7bc11

Comment 43

[Andrei Vaida [:avaida]]

(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.

Comment 44

[Kostas]

(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).

Comment 45

[Ryan VanderMeulen [:RyanVM]]

Is this worth trying to rebase for ESR52?

Comment 46

[Jean-Yves Avenard [:jya]]

Attachment: P1. handle EOS during seeking. r=jya

MozReview-Commit-ID: DPT3t1pi6o1

Comment 47

[Jean-Yves Avenard [:jya]]

Attachment: 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

Comment 48

[Jean-Yves Avenard [:jya]]

Attachment: P1. handle EOS during seeking. r=jya

MozReview-Commit-ID: DPT3t1pi6o1

Comment 49

[Jean-Yves Avenard [:jya]]

Attachment: 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

Comment 50

[Jean-Yves Avenard [:jya]]

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.

Comment 51

[JW Wang [:jwwang] [:jw_wang]]

Let me download ESR52 to refresh the memories.

Comment 52

[JW Wang [:jwwang] [:jw_wang]]

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

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

LGTM.

Comment 53

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 54

[Gerry Chang [:gchang]]

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.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/7ccb26caa02f
https://hg.mozilla.org/releases/mozilla-esr52/rev/a93c1a40f0d8