The original float is not needed for layout, and thus there's no need to keep it
around.
This was presumably used by the old style system, but now it doesn't seem
useful, and is always `none`.
Differential Revision: https://phabricator.services.mozilla.com/D34442
--HG--
extra : moz-landing-system : lando
The tile cache is 352 bytes large and in the majority of cases picture primitives don't have one, so this saves a few KB of ram in typical pages reduces the likely hood of hitting OOM crashes while growing the primitives vector.
Differential Revision: https://phabricator.services.mozilla.com/D34346
--HG--
extra : moz-landing-system : lando
Hitting Ctrl+ArrowRight didn't have any effect on windows/linux.
The patch fixes this and add a test to make sure a user can
navigate from word to word using Ctrl (or Alt on OSX) and
Arrow Left/Right keys.
Differential Revision: https://phabricator.services.mozilla.com/D34312
--HG--
extra : moz-landing-system : lando
Currently, `HTMLEditor::GetSelectedElement()` is not used in mozilla-central
and mainly used for handling double clicks in the editor with its complicated
path. In most cases, users don't want double clicks to cause showing
property dialog in mail composer. Therefore, we must be able to stricter in
the complicated path.
This patch adds new check whether the selected range ends immediately before
a `<br>` element. If it's end at a `<br>` element, we shouldn't treat found
element as selected.
Note that when `<a href="...">` element is double-clicked, the element itself
is selected like `<img>` element. So, we don't need to worry about the case
which is that users probably want to update a link with double-clicking since
such case is handled by the first optimized path in the method.
Differential Revision: https://phabricator.services.mozilla.com/D34335
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Rather than attempting to determine when the Once policy StaticPrefs should be set we initialize them when one of the getter gets called. They become immutable after that.
In a future change we will prevent those values to ever be changed once they have been initialized.
Differential Revision: https://phabricator.services.mozilla.com/D33440
--HG--
extra : moz-landing-system : lando
When we create the SharedPreferenceMap we store the value of the Once pref in it. All child processes will now read the Once pref from the read-only SharedPreferenceMap.
This makes the Once prefs immutable once we start the first child process.
Differential Revision: https://phabricator.services.mozilla.com/D33421
--HG--
extra : moz-landing-system : lando
This allows for an entry to not show in about:config.
This will be used to store Once StaticPrefs once they become immutable.
Differential Revision: https://phabricator.services.mozilla.com/D33420
--HG--
extra : moz-landing-system : lando
Will also silence static analysis in phabricator whenever a caller of this code is used.
Differential Revision: https://phabricator.services.mozilla.com/D33419
--HG--
extra : moz-landing-system : lando
The tests expects that setting the preference would lead to a different behaviour. However, this pref was set as once and as such immutable until the next restart.
Differential Revision: https://phabricator.services.mozilla.com/D34282
--HG--
extra : moz-landing-system : lando
Element.nodeName is usually all-caps, and we were testing lower cased version,
which brought erroneous results.
The test wasn't picking those errors because we were creating the element from
a XHTML document, where Element.nodeName keep the casing used for their creation.
The test is modified to deal with an HTML document instead.
After the test was modified, I could see it was failing, and was then able to
do the actual feature fix.
Differential Revision: https://phabricator.services.mozilla.com/D34149
--HG--
rename : devtools/server/tests/browser/browser_inspector-inactive-property-helper.js => devtools/server/tests/mochitest/test_inspector-inactive-property-helper.html
extra : moz-landing-system : lando
A lot of the overhead in MoofParser::RebuildFragmentedIndex(BoxContext&) is
copying data into the BoxReader's storage. In the MSE case the underlying data
being read is actually buffered in memory, so we may be able to just read the
in-memory data directly, avoiding the copy.
Note that the data may not be stored in a single contiguous ResourceItem in the
SourceBufferResource's ResourQueue. If so, it's not as straightforward to hand
out a uint8_t* to the underlying data. So we just copy it in that case for
simplicity. In most cases, the data in a single MP4 box would be appended in a
single append, and so is likely to be in a single ResourceItem.
Differential Revision: https://phabricator.services.mozilla.com/D33877
--HG--
extra : moz-landing-system : lando
If you look down the call stacks inside MoofParser::RebuildFragmentedIndex(),
you'll see we spend most of the time inside BoxReader, e.g.:
https://perfht.ml/31b42u3
Each Box we create is read by a BoxReader, which makes a copy of the Box's
contents. We spend a bunch of time allocating the memory to store the copy on
the heap.
Since the allocations here are short lived (we delete the boxes at scope exit
of RebuildFragmentedIndex()), we can speed up the allocation by using a bump
allocator here. This means we hit malloc() and free() a lot less.
Note that Twitch only hits this allocator with allocations which are less
than 100 bytes. On YouTube we see a different pattern; there are still a lot
of allocations less than 100 bytes, but also a significant number which are
between 1500-1700 bytes.
The bump allocator lives on the BoxContext, so will be deallocated on scope
exit of MoofParser::RebuildFragmentedIndex().
Differential Revision: https://phabricator.services.mozilla.com/D33876
--HG--
extra : moz-landing-system : lando
Twitch is appending samples with small gaps between them, and the gaps span
Moof boundaries.
This means we end up have buffered ranges with lots of small gaps, and keeping
these up to date is expensive.
So remember the CTS of the last sample in each track, and pass that in when
parsing new Moofs. We can then remove the gaps, which makes our buffered
ranges simpler.
Note that Twitch often has a 1 microsecond gap between audio samples, but up to
1 millisecond gap between video samples; so we use a different threshold for
audio and video.
Differential Revision: https://phabricator.services.mozilla.com/D33875
--HG--
extra : moz-landing-system : lando
Twitch usually evicts data at the start of its buffered range, so handling this
case specially means we'll avoid the expensive general case.
Differential Revision: https://phabricator.services.mozilla.com/D33874
--HG--
extra : moz-landing-system : lando
When playing Twitch we can spend a lot of time in
TrackBuffersManager::InsertFrames() doing a
TimeIntervals::operator+=(TimeIntervals): https://perfht.ml/30CekTS
Twitch normally appends a range which touches the existing range. So we can
fast-path this case, and avoid the expensive reallocations, CheckedInt
comparisons and so forth in TimeIntervals::operator+=(TimeIntervals).
Note that this fast-path is already in place in
IntervalSet::operator+=(Interval), so we can just take that path when the size
of the incoming IntervalSet is 1.
Differential Revision: https://phabricator.services.mozilla.com/D33873
--HG--
extra : moz-landing-system : lando
This causes slowdowns in mozilla::TrackBuffersManager::Seek() due the time it
takes to sort: https://perfht.ml/30DqGLJ
Note the array of intervals should already be sorted, so we shouldn't need to
do the quicksort again.
We can also do the merging of intervals in place, rather than allocating a new
array to hold the normalized intervals.
Differential Revision: https://phabricator.services.mozilla.com/D33872
--HG--
extra : moz-landing-system : lando
The demuxer's low level byte reading abstraction is ResourceQueue::CopyData(),
but that's doing a linear scan through its list of ResourceItems in
GetOffsetAt() in order to find the ResourceItem in which the data to be read
lies. This sometimes shows up at the bottom of call stacks.
We could make this faster by doing a bisection search to find the ResourceItem
we need.
Differential Revision: https://phabricator.services.mozilla.com/D33871
--HG--
extra : moz-landing-system : lando
Profiling Twitch we see a significant amount of time at the bottom of our call
stacks in the MoofParser creating Box objects. Most of the time spend therein
is allocating and copying into an nsTArray. This is us copying the Box's header
into Box::mHeader. The reallocation and append are expensive. It turns out we
only use the box header in one place; when reporting the PSSH boxes up to EME.
So in the non-EME case, the storage of the Box header is a complete waste of
time and space.
So we can change the Box class to instead read the header from its storage when
we need to retrieve the complete PSSH boxes.
Differential Revision: https://phabricator.services.mozilla.com/D33870
--HG--
extra : moz-landing-system : lando
The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Now they both work in opt builds, and they both work with advanced layers.
For consistency, layers.dump-client-layers is also modified to work in
opt builds.
Differential Revision: https://phabricator.services.mozilla.com/D34413
--HG--
extra : moz-landing-system : lando
With this change, the tests in question pass on desktop, except for
scrollbar-zoom-resolution-2.html which is annotated as failing.
Differential Revision: https://phabricator.services.mozilla.com/D32775
--HG--
extra : moz-landing-system : lando
