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
When calculating position percentage, `top` should divide the height of the video rendering area, and `left` should divide the width of the video rendering area.
Differential Revision: https://phabricator.services.mozilla.com/D40900
--HG--
extra : moz-landing-system : lando
Make it a hard error when the sandbox returns non-unicode strings.
This should help quickly catch any remaining non-unicode string that
are not caught by automation.
Differential Revision: https://phabricator.services.mozilla.com/D42607
--HG--
extra : moz-landing-system : lando
As a consequence, we can replace the encoded_open function that did the
same in an opt-in manner.
Differential Revision: https://phabricator.services.mozilla.com/D42605
--HG--
extra : moz-landing-system : lando
Because most calling places in python configure don't actually want to
deal with encodings, although in practical terms they should, make
get_cmd_output handle it itself.
Places that explicitly do want bytes can keep using subprocess directly.
Differential Revision: https://phabricator.services.mozilla.com/D42604
--HG--
extra : moz-landing-system : lando
It only happens when things go badly, which is why it doesn't cause
problems, but when moving things around, triggering the error, we
currently get a formatting error rather than the actual error.
Differential Revision: https://phabricator.services.mozilla.com/D42602
--HG--
extra : moz-landing-system : lando
In bug 1542830 I need to generate an import library from a .DEF file. The
`llvm-dlltool` utility is the tool to support this.
This change adds detection for the aforementioned utility and also configures
the required flags.
Differential Revision: https://phabricator.services.mozilla.com/D41817
--HG--
extra : moz-landing-system : lando
This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().
Differential Revision: https://phabricator.services.mozilla.com/D42763
--HG--
extra : moz-landing-system : lando
Android artifacts (GeckoView AARs, GeckoViewExample (and Fennec) APKs)
require native libraries (`libxul.so`) and an omnijar (`omni.ja`).
These are produced by `mach package` (really, the `stage-package`
target). Engineers essentially never want a build without a package
for mobile/android. This adds mobile/android-only tiers that run
`mach package` and then `mach android assemble-app`. The latter
consumes `libxul.so` and `omni.ja` to produce _all the things_
relevant to GeckoView engineers.
Differential Revision: https://phabricator.services.mozilla.com/D41450
--HG--
extra : moz-landing-system : lando
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
1. Add `this` to the log so that it's easier to debug a nested column
balancing
2. Print the struct fields the same as their names.
Differential Revision: https://phabricator.services.mozilla.com/D42711
--HG--
extra : moz-landing-system : lando
nsBlockFrame already prepares the available block-size for
ColumnSetFrame with ColumnSetWrapper's block-size and max-block-size
applied. (ColumnSet's computed block-size and max block-size is always
unconstrained when column-span is enabled.)
Differential Revision: https://phabricator.services.mozilla.com/D42710
--HG--
extra : moz-landing-system : lando
Before bug 1411422, a ::-moz-column-content has height:100%, so it could
go into this path if ColumnSet's available block-size is unconstrained.
However, after bug 1411422, height:100% was removed for
::-moz-column-content. That is, its computed block-size is
unconstrained, so it can't go into this path. This applies regardless of
whether column-span is enabled or not.
Differential Revision: https://phabricator.services.mozilla.com/D42708
--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
Masayuki Nakano
Alastor Wu
Julian Descottes
Kagami Sascha Rosylight
Cameron Kaiser
Arun Kumar Mohan
Mike Hommey
Aaron Klotz
Eric Rahm
Steve Fink
Markus Stange
Nick Alexander
Brian Hackett
Andrew McCreight
Dan Glastonbury
Bogdan Tara
Ting-Yu Lin
Stephen Horlander
Logan Smyth
Jason Laster
Daniel Holbert
Gerald Squelart