Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.
Differential Revision: https://phabricator.services.mozilla.com/D40756
--HG--
extra : moz-landing-system : lando
This test's reference case occasionally (intermittetly) fails to do ink
skipping, so let's just turn off the ink-skipping preference for now to
avoid triggering too much intermittent orange.
Differential Revision: https://phabricator.services.mozilla.com/D42713
--HG--
extra : moz-landing-system : lando
Some marker payloads rely on JS and XPCOM objects (e.g., nsCString), so we need
to (de)serialize these.
Differential Revision: https://phabricator.services.mozilla.com/D42635
--HG--
extra : moz-landing-system : lando
Backtraces (that are kept in some marker payloads) are stored in a small
ProfileBuffer, we will need to store that data, which will happen to be inside
a BlockRingBuffer, so BlockRingBuffer needs to be able to (de)serialize itself!
This is done by storing the contents in the active buffer range, and some extra
data, to later reconstruct a BlocksRingBuffer that looks like the original.
Depends on D42496
Differential Revision: https://phabricator.services.mozilla.com/D42634
--HG--
extra : moz-landing-system : lando
Markers and their payloads contain all kinds of objects that we'll need to
serialize into a BlocksRingBuffer (new ProfileBuffer storage).
This patch will add functions to:
- Compute the size needed to store objects,
- Write multiple objects into a BlockRingBuffer entry,
- Read objects back from an entry.
And it will provide a number of useful de/serialization helpers for:
- Trivially-copyable objects,
- Strings of different types,
- Raw pointers (with some safety guards to avoid surprises),
- Tuples (to store multiple sub-objects),
- Spans,
- Maybe (for optional objects),
- Variant.
This should be enough to store most kinds of data. Further specializations
can&will be written as necessary for more complex or obscure types.
Differential Revision: https://phabricator.services.mozilla.com/D42496
--HG--
extra : moz-landing-system : lando
This Change removes all call to Exists() in Directory Provider component, which creates the possibility for the componenet to return an empty list. SearchService.jsm is modified to handle this possibility.
Differential Revision: https://phabricator.services.mozilla.com/D42772
--HG--
extra : moz-landing-system : lando
The functionality has been moved to DatabaseOperationBase::BindKeyRangeToStatement
resp. DatabaseOperationBase::GetBindingClauseForKeyRange as part of Bug 994190.
Differential Revision: https://phabricator.services.mozilla.com/D41024
--HG--
extra : amend_source : 2c58011d334a35e808e93c1876080db5f83ee659
Disable -ftrivial-auto-var-init for DllBLocklistWin.cpp with clang-cl because the file's interceptions happen so early in the main process that the loader hasn't yet resolved the import of memset (used by -ftrivial-auto-var-init) from vcruntime140.dll.
Disable -ftrivial-auto-var-init on Linux32 because it causes some xpcshell test failures.
Differential Revision: https://phabricator.services.mozilla.com/D42273
--HG--
extra : moz-landing-system : lando
It's called immediately before setting `mHTMLEditor` and sets `mHTMLEditor` to
`nullptr`. So, it does nothing actually. We can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D42771
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::IsInlineNode()` is a wrapper of
`HTMLEditor::NodeIsInlineStatic()`, but returns opposite value.
This patch moves it into `HTMLEditor` and names it with same rule as
`NodeIsBlockStatic()`.
Note that this method may return true if given node is unexpected node type.
E.g., comment node, CDATA node, etc. However, it's not scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D42770
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::IsBlockNode()` just wraps `HTMLEditor::NodeIsBlockStatic()`
and all its users will be moved into `HTMLEditor`. Therefore, we should
unwrap it.
Differential Revision: https://phabricator.services.mozilla.com/D42769
--HG--
extra : moz-landing-system : lando
Add wpt `snap-to-line.html` to ensure that the cue with `snap-to-line=false` can be placed in correct place.
Setting `line` as percentage will make cue's `snap-to-line` to `false` automatically [1], and we also set `position` and `align` to test if we can handle all these attributes well when `snap-to-line` is false.
[1] https://www.w3.org/TR/webvtt1/#ref-for-webvtt-cue-snap-to-lines-flag-9
Differential Revision: https://phabricator.services.mozilla.com/D42433
--HG--
extra : moz-landing-system : lando
We have already had a exactly same function, so can remove a redundant one.
Differential Revision: https://phabricator.services.mozilla.com/D41132
--HG--
extra : moz-landing-system : lando
When adjusting cues with `snapToLines=false`, first we would generate an array with all different axises which we would use to move cue on the specific direction.
However, for the different writing directions, we should have different priority for the moving directions.
For example, if the wriring direction is `horizontal`, which means cues will grow from the top to the bottom, then moving cues along the `y` axis should be more important than moving cues along the `x` axis, and vice versa for those cues growing from the left to right, or from the right to the left.
After decided the moving direction, then we have to decide the moving offset. Now we use line box's Bsize as a basic moving unit.
Moving cues, however, by such as large distance as a time would cause too many redudant space between cue boxes, which doesn't provide a good enough visual arrangement result. Therefore, we divide the Bsize by a factor, which can control the granularity of the moving unit and can still preverse a reasonable space between boxes. That can provide way better visual result than the one we had used before, and still has certain good performance comparing with moving 1px at a time.
Differential Revision: https://phabricator.services.mozilla.com/D41131
--HG--
extra : moz-landing-system : lando
When adjusting the position of the cue box, if we can't find a proper place to display the cue within the video rendering area, we should return `null` and not to show it on the screen.
Differential Revision: https://phabricator.services.mozilla.com/D40901
--HG--
extra : moz-landing-system : lando
