Closed
Bug 1359058
Opened 7 years ago
Closed 7 years 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'
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla55
People
(Reporter: rick3162, Assigned: jya)
References
()
Details
(Keywords: regression, testcase-wanted, Whiteboard: [platform-rel-Amazon][platform-rel-IMDb])
Attachments
(6 files, 2 obsolete files)
511.12 KB,
image/png
|
Details | |
59 bytes,
text/x-review-board-request
|
jya
:
review+
|
Details |
59 bytes,
text/x-review-board-request
|
jya
:
review+
ritu
:
approval-mozilla-beta+
|
Details |
59 bytes,
text/x-review-board-request
|
mozbugz
:
review+
ritu
:
approval-mozilla-beta+
|
Details |
896 bytes,
patch
|
jwwang
:
review+
gchang
:
approval-mozilla-esr52+
|
Details | Diff | Splinter Review |
1.46 KB,
patch
|
Details | Diff | Splinter Review |
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•7 years ago
|
||
Comment 2•7 years 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
> 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•7 years ago
|
||
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•7 years 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)
Comment 6•7 years ago
|
||
Would it be possible that we can add some test or enhance our current tests?
Priority: -- → P1
Assignee | ||
Comment 7•7 years 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•7 years 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+
Comment 10•7 years ago
|
||
Thanks!
Assignee | ||
Comment 11•7 years 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...
Comment 12•7 years ago
|
||
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•7 years ago
|
||
yes.. somehow, even when those keyframe aren't ones... they decode well anyway...
need to check what's going on...
Assignee | ||
Comment 14•7 years 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?
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 17•7 years 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+
Updated•7 years ago
|
status-firefox-esr52:
--- → affected
Version: Trunk → 51 Branch
Comment 18•7 years ago
|
||
(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)
Updated•7 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-Amazon][platform-rel-IMDb]
Comment 19•7 years ago
|
||
Is this a new regression for 53 or was it also broken in 52?
Keywords: regressionwindow-wanted
Assignee | ||
Comment 20•7 years ago
|
||
it was also broken in 52...
it is a regression though.
Comment 21•7 years ago
|
||
Updated•7 years ago
|
platform-rel: ? → +
Assignee | ||
Comment 22•7 years ago
|
||
Anthony? can you please review this patch?
Flags: needinfo?(ajones)
Assignee | ||
Updated•7 years ago
|
Attachment #8861970 -
Flags: review?(ajones) → review?(gsquelart)
Comment 23•7 years 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•7 years 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
Comment 25•7 years ago
|
||
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•7 years 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)
Updated•7 years ago
|
Keywords: testcase-wanted
Updated•7 years ago
|
Flags: needinfo?(ajones)
Comment 28•7 years ago
|
||
Too late to fix for 53 but we could likely still take a patch for 54.
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 31•7 years ago
|
||
It looks like IMDB has fixed their videos.. frames are properly tagged now.
Comment 32•7 years 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
Comment 33•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0cf76b87767d
https://hg.mozilla.org/mozilla-central/rev/40d98a26598e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Comment 34•7 years ago
|
||
Please request uplift on this, if you think it's appropriate, when you get a chance.
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 35•7 years 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?
Comment 36•7 years ago
|
||
(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•7 years 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•7 years ago
|
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 38•7 years 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•7 years ago
|
||
Above I'm referring to the IMDB files which had all frames marked a P-Frame.
Hi Kostas, could you please verify that this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(rick3162)
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+
Attachment #8861970 -
Flags: approval-mozilla-beta+
Comment 42•7 years ago
|
||
bugherder uplift |
Comment 43•7 years ago
|
||
(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•7 years 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)
Assignee | ||
Comment 46•7 years ago
|
||
MozReview-Commit-ID: DPT3t1pi6o1
Assignee | ||
Comment 47•7 years ago
|
||
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•7 years ago
|
||
MozReview-Commit-ID: DPT3t1pi6o1
Assignee | ||
Comment 49•7 years ago
|
||
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•7 years ago
|
Attachment #8889568 -
Attachment is obsolete: true
Flags: needinfo?(jyavenard)
Assignee | ||
Updated•7 years ago
|
Attachment #8889569 -
Attachment is obsolete: true
Assignee | ||
Comment 50•7 years 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)
Comment 51•7 years ago
|
||
Let me download ESR52 to refresh the memories.
Comment 52•7 years ago
|
||
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 53•7 years ago
|
||
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 54•7 years ago
|
||
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•7 years ago
|
||
bugherder uplift |
You need to log in
before you can comment on or make changes to this bug.
Description
•