This ensures that the vsync notifications don't race ahead of the touch
events, which can result in jank if the APZ sampling happens before the
touch events update the scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D11042
--HG--
extra : moz-landing-system : lando
This assumes that a lineno of 0 denotes a "file-level" issue, e.g an issue
associated with the filename. In the future it might be better to treat these
"file-level" issues as first class citizens. This would involve updating things
like formatters, editor integrations and review bot to not assume a lineno.
Differential Revision: https://phabricator.services.mozilla.com/D10383
--HG--
extra : moz-landing-system : lando
This ensures that the test always work whenever the sample contains an extradata that is different to the info specified in the VideoInfo.
Depends on D10908
Differential Revision: https://phabricator.services.mozilla.com/D10909
--HG--
extra : moz-landing-system : lando
For AVC1 content (where the SPS/PPS is provided out of band), we would use VideoInfo has found in the container's metadata which may not always be correct.
Likely the reason on why we had bug 1498788 (decoded sample size didn't match the video config's dimensions)
We also always set the MediaRawData::mTrackInfo member for all samples, not just the first one as it's the right thing to do.
Depends on D10907
Differential Revision: https://phabricator.services.mozilla.com/D10908
--HG--
extra : moz-landing-system : lando
So that we can later expand and use it for other codecs.
Differential Revision: https://phabricator.services.mozilla.com/D10907
--HG--
rename : dom/media/platforms/wrappers/H264Converter.cpp => dom/media/platforms/wrappers/MediaChangeMonitor.cpp
rename : dom/media/platforms/wrappers/H264Converter.h => dom/media/platforms/wrappers/MediaChangeMonitor.h
extra : moz-landing-system : lando
We were clamping the playback rate properly if the decoder had been setup already, but not if setting it before playback started.
Differential Revision: https://phabricator.services.mozilla.com/D11005
--HG--
extra : moz-landing-system : lando
Changes:
- under a specific code path such as:
`./mach <test_type> --debugger`
there exists now additional checks for IndexError when attempting to parse the debugger program name.
- print a nicer error message if user failed to properly specify the debugger program name.
- raise exit code of 1 if IndexError is raised.
Others:
- code comments updated to better reflect/describe what the section does.
Differential Revision: https://phabricator.services.mozilla.com/D10987
--HG--
extra : moz-landing-system : lando
Implemented the manual linting fixes for docshell/test/navigation, docshell/test/unit and docshell/test/unit_ipc
Depends on D9430
Differential Revision: https://phabricator.services.mozilla.com/D10080
--HG--
extra : moz-landing-system : lando
Enabled ESLint for:
* docshell/test/navigation/**
* docshell/test/unit/**
* docshell/test/unit_ipc/**
Changed .eslintignore to allow for this and ran ./mach eslint --fix on the above directories and checked automatic fixes
Differential Revision: https://phabricator.services.mozilla.com/D9430
--HG--
extra : moz-landing-system : lando
This generates several new things:
* store_count and store_offset in the HistogramInfo struct.
store_count indicates the number of stores the histogram is registered in.
store_offset is an offset into the gHistogramStoresTable array.
If store_count == 1 && store_offset == UINT16_MAX, then the histogram is only in the main store.
* gHistogramStoresTable: An array containing the actual offsets into gHistogramStringTable to get a store's name
Depends on D10921
Differential Revision: https://phabricator.services.mozilla.com/D10922
--HG--
extra : moz-landing-system : lando
This generates new things:
* store_count and store_offset in the ScalarInfo struct.
store_count indicates the number of stores the scalar is registered in.
store_offset is an offset into the gScalarStoresTable array.
If store_count == 1 && store_offset == UINT16_MAX, then the scalar is only in the main store.
* gScalarStoresMap: An array containing the offsets into gScalarsStringTable to get a store's name
Depends on D10920
Differential Revision: https://phabricator.services.mozilla.com/D10921
--HG--
extra : moz-landing-system : lando
There were two unrelated buffering problems in nsWebPDecoder. The first
was with the decoder contract. We are expected to loop until the
iterator is unable to provide more data, and wait for the SourceBuffer
to reschedule us, where as nsWebPDecoder::DoDecode only did one pass.
Thus when something yielded wanting more data, we would just wait
forever.
The second was the integration with the libwebp API. We are expected to
retry when we receive SUSPENDED from the decoder, as it decided to yield
pixels instead of continuing to decode as many as possible.
The tests did not cover the first problem because multi chunk decoder
tests do not use SourceBuffer scheduling. This is an oversight. They now
will write a chunk of data, let the SourceBuffer reschedule the decoder,
and repeat until all of the data has been written.
The tests did not cover the second problem because all of the reference
WebP images are too small. This patch adds a new test with a large WebP
image (converted from a Mozilla all hands photo of lanyards). This
should actually trigger the SUSPEND behaviour of libwebp.
Differential Revision: https://phabricator.services.mozilla.com/D10817
