those unwrap_or are mostly seen during the batching, where we should asssume that
the primitives are not clipped out and just unwrap() accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39940
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
Not happy with all these void pointer stuff, but I think this is slightly nicer
to read.
Also not happy with what clang-format has done to my code ;)
I've removed the comment about zoom because it's not clear to me it is still
relevant, but I've preserved the order because, should we have similar stuff
going on, it seems slightly better, and I'm moderately sure the rest of the
callers don't really care.
I think closures coerced to function pointers are nicer (I considered putting
this on a template or using std::function, maybe, this was less code specially
given some callers of EnumerateExternalResources may or may not be hot...),
but if you want me to keep stuff out of line, or move the whole thing to
std::function<> or templates let me know.
Differential Revision: https://phabricator.services.mozilla.com/D40249
The test unfortunately passes without the patch because for HTML documents we go
through DoUpdateCharSet which ends up through RebuildAllStyleData. So I think
this bug is not web-observable.
I'll file a bug to try to optimize parts of that away, since I think that we can
be doing a bit of wasteful work there for somewhat common cases...
Differential Revision: https://phabricator.services.mozilla.com/D39737
--HG--
extra : moz-landing-system : lando
Bug 1546136 wrapped subprocess execution output to capture cmake's, but
at the detriment of other output, and hiding everything unless an error
occurs.
So instead, we only capture the output when the called process is cmake,
and even when it is cmake, we don't pipe stderr at all (since we only
care about cmake's stdout) and we print out stdout as it comes in rather
than later. We then later check the output for hints at the more useful
cmake logs and dump them.
While here, add verbosity to ninja output (which gives the command
lines, rather than generic "Building foo.o" output).
Differential Revision: https://phabricator.services.mozilla.com/D40142
This was originally (I assume) used to control checking out build-tools, in a previous iteration of
our automation for checking out source. Our current tool doesn't look at this variable, and doesn't
support checking out build-tools.
Differential Revision: https://phabricator.services.mozilla.com/D40234
`IMEContentObserver` treats `<br>` elements as linefeed, but ignores padding
`<br>` elements. Padding `<br>` element for last empty line was inserted as
normal `<br>` element and then, its attribute was set by editor. Therefore,
`IMEContentObserver` needed to observe attribute changes. However, editor
stops using attribute to mark as padding and stops inserting as normal `<br>`
element first (i.e., inserting `<br>` after setting its flag). Therefore,
`IMEContentObserver` does not need to observe attribute changes anymore.
Differential Revision: https://phabricator.services.mozilla.com/D39861
--HG--
extra : moz-landing-system : lando
Stopping using attribute for "moz-br", `IMEContentObserver` cannot know when
new `<br>` element is changed to padding element for empty last line.
Therefore, editor needs to insert padding `<br>` element after setting the
flag properly. Then, `IMEContentObserver` does not need to recompute the
length of `<br>` element (if it's for padding, it computes the length as 0).
Unfortunately, `TextEditor::InsertBrElementWithTransaction()` is used in too
many places and it already has optional argument. Therefore, it's difficult
to change it. However, we should share the preparation before creating `<br>`
element in it with new method. Therefore, this patch creates
`EditorBase::PrepareToInsertBRElement()` to share the preparation point (almost
just moved from the method). Then, new method is created as
`EditorBase::InsertPaddingBRElementForEmptyLastLineWithTransaction()` because
it's used both in `TextEditor` and `HTMLEditor`. Finally, `TextEditor` won't
insert `<br>` element with `InsertBrElementWithTransaction()`. Therefore, it's
moved to `HTMLEditor` with renaming to `InsertBRElementWithTransaction()`.
Differential Revision: https://phabricator.services.mozilla.com/D39860
--HG--
extra : moz-landing-system : lando
`TextEditRules::CreateBR()` is used only by
`HTMLEditRules::InsertBRIfNeededInternal()` and it just calls
`TextEditor::InsertBrElementWithTransaction()`. Therefore, we can get rid of
it. Then, `CreateBRInternal()` can be renamed to
`CreatePaddingBRElementForEmptyLastLine()` since it's shared only by
`CreateBR()` and `CreatePaddingBRElementForEmptyLastLine()`.
Differential Revision: https://phabricator.services.mozilla.com/D39859
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Andreas Pehrson
Dzmitry Malyshau
Julian Descottes
Zibi Braniecki
Cosmin Sabou
arthur.iakab
Dan Minor
Mihai Alexandru Michis
Honza Bambas
Micah Tigley
Greg Tatum
Vijay Budhram
Jan Horak
Kate Hudson
Nicolas Chevobbe
Matthew Gaudet
Alphan Chen
Geoff Brown
Andreea Pavel
mandy cheang
Mike Hommey
Tom Prince
Masayuki Nakano