The additional `ifndef IS_LANGPACK` Makefile bits turned out to be unnecessary,
as langpack packaging excludes ini files:
https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/toolkit/locales/l10n.mk#220
We already don't have this wrapping around updater.ini so it doesn't seem
harmful.
MozReview-Commit-ID: 7kmg1AIVLcl
--HG--
extra : rebase_source : d0ea61865ad0b07054b894335f9266f19c1495f5
extra : source : 0e485a8fdc3f45ae4cdad75e010765fb48aa20c4
We implemented v1.1 of the U2F specification, which wasn't publicly published
at the time. Bug 1276968 was to come back and fix those links, so here it is.
MozReview-Commit-ID: 8hprQncPwcO
This makes chunks and timeouts on the Windows coverage build closer to what we have defined for the Linux build. We can improve them over time with some experience on how they behave in the field.
--HG--
extra : rebase_source : 5f7fe5ee00f333e4c0f87475f9c803f0f1e6f701
The difference between nsDocument::IsWebAnimationsEnabled and
nsContentUtils::AnimationsAPICoreEnabled is that the former checks the caller
type and treats the preference as set for system callers which is particularly
needed for enabling things like the getProperties() API for DevTools etc.
Generally in API-facing call sites we have a JS context / CallerType and so we
want to distinguish between system callers and non-system callers. However, for
a few internal uses--specifically filling-in missing keyframes--we don't care
about the caller type and always follow the pref setting.
That may or not be quite what we want, but this patch doesn't change that except
for one call site: KeyframeUtils::GetKeyframesFromObject. This patch changes
GetKeyframesFromObject from *not* checking the caller type to checking the
caller type. That seems to be the correct behavior here since this is called
from KeyframeEffectReadOnly::SetKeyframes(JSContext*, JS::Handle<JSObject*>,
ErrorResult&) (i.e. a JS API-facing call site) where we *should* enable the full
API when the caller is chrome code.
MozReview-Commit-ID: FQJBk3zytwd
--HG--
extra : rebase_source : 577bca1e551e39fecfab309f64c993eba110337f
As I discussed in #19277, I'd like to change the implementation for `From` of font variant to use macro, `impl_gecko_keyword_conversions`.
r? @emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes update `From` impl for font variant to use macro `impl_gecko_keyword_conversions`.
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: 63bd783c55ab0c0f9abb1a8fa07f20932c77b764
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3b84f9e94c75f791a42835a47e0beb989f628bcf
Otherwise we do update keyframes data unnecessarily.
MozReview-Commit-ID: ys4BEF1kxX
--HG--
extra : rebase_source : 725aef9a4be9296bc992f6128be7c62b4c2b01e1
This requires adding a constructor, which is used in a placement new.
MozReview-Commit-ID: 3v6843D5DMu
--HG--
extra : rebase_source : 780902ae8e761bdf1141f24bf5594ce910ea32b4
And rename it as ToSetting(). This requires also moving
AssignPrefValueToDomPrefValue into PrefHashEntry.
MozReview-Commit-ID: 8ntNZJt9rhv
--HG--
extra : rebase_source : 5dd5a2c570b2ceefb506b4051c414b06d27a95f2
This patch:
- partially inlines GetPrefValueFromEntry() at its two call sites, to avoid
repeating the kind check;
- renames it as AssignPrefValueToDomPrefValue().
MozReview-Commit-ID: BUBk3ML6h5O
--HG--
extra : rebase_source : eb12adf4af2ee05356af6b2b4f346aa3425ff438
PrefTypeFlags is a class with a lot of smarts (i.e. methods). PrefHashEntry is
a class with little smarts. This is silly, because PrefTypeFlags is essentially
an internal implementation detail of PrefHashEntry.
This patch merges PrefTypeFlags into PrefHashEntry, so that PrefHashEntry has
all the smarts. This means lots of `pref->mPrefFlags.Foo()` calls become
`pref->Foo()`.
The patch also changes the representation of the type and flags within
PrefHashEntry to use bitfields, which avoids the need for a Flags type and is
much simpler than the old approach.
MozReview-Commit-ID: 4Yt9OtBzh9e
--HG--
extra : rebase_source : 18fc01217aeaee7057b3d9a54b18cae45be5538f
They are guaranteed to be zeroed already by PLDHashTable.
MozReview-Commit-ID: LBeGa9ABYc3
--HG--
extra : rebase_source : f767d0d20cfb1c187496be20fff4cce43c768ccd
It's good to save some copy constructor calls.
MozReview-Commit-ID: 6TveqwkOvc0
--HG--
extra : rebase_source : 02e678f985c074f6c972cf8478e233aa5e4607db
This private method DoAutoScroll() modifies aPoint inside of it, and none of
other callers (StartAutoScrollTimer() and nsAutoScrollTimer::Notify()) read
aPoint afterwards, so we make aPoint pass by value rather than pass by
non-const-reference. This is necessary for later parts.
MozReview-Commit-ID: 9PtxFXIka7X
--HG--
extra : rebase_source : 3bd47f071b3cecdc439ebc3b56c6a4f7ef56eff8
The idea is the following:
Behind-window vibrancy is mostly rendered by the window server. For a given
vibrant region of a window, the window server renders a vibrancy "backdrop",
which is a blurred version of everything that's behind that region, modified
with a color tint and blended in some way. Then it puts our actual window
contents on top of that background.
The backdrop's shape is usually a rectangle. If we don't want it to be a
rectangle, we need to tell the window server about the shape that we want it to
be. We can't just "draw" a different shape in our own rendering, because our
own rendering is merely placed on top of the backdrop - but here we want to
modify the shape of the backdrop itself.
NSVisualEffectView lets us set a mask image on the view. If this view is the
content view of a window, then the view will automatically communicate the mask
image to the window server.
Traditionally, our popup windows have had a ChildView as their content view. If
we now want an NSVisualEffectView to be the content view of the window, then we
need to nest the ChildView inside that NSVisualEffectView.
But this NSVisualEffectView is only needed when the window is vibrant and the
vibrancy backdrop needs to have a certain shape. This is the case for our menus
which need to have rounded corners. If the window transitions to being
non-vibrant, or not needing a special shape, then we can go back to the way our
window's NSView hierarchy has worked traditionally. So we need to reparent
NSViews during those transitions.
MozReview-Commit-ID: Bo2VzjhhR0A
--HG--
extra : rebase_source : 9eb463cc68c16c3b9281b57455330969c5e2642c
NotifyDataEnded() runs off the main thread which might set mChannelEnded
wrongly after NotifyChannelRecreated reset it on the main thread.
We should reset the flags in NotifyDataStarted() which indicate a new load has begun.
MozReview-Commit-ID: Gi6PFXwMJqc
--HG--
extra : rebase_source : 85bb2c25a55cce4b3c3f023bf4c02fe5d1de7552
extra : source : 2f8c5518bf615f9190f87032568fc53037bc6fc1
There are some works to do when we allow a stream whose download ends abnormally
to continue sharing the resource:
1. Abort Read() when download error happens. We might still have a chance to
get all the data successfully. However, it doesn't really matter since
the stream data is incomplete and we will encounter decode errors sooner
or later.
2. Update() needs to check mChannelEnded since an ended stream will not
download data needed by other streams.
MozReview-Commit-ID: LGCecQ5rpzq
--HG--
extra : rebase_source : 17a91a1cfd145344c3c0a29b80665cb99ce20746
extra : source : 0947c12b035acc9fba02e89dc87b3a17f84cf2e5
Ted Mielczarek
J.C. Jones
Yura Zenevich
Lee Salzman
Joel Maher
Alexander Surkov
Jon Coppeard
Rail Aliiev
Andrea Marchesini
Paul Bone
Philip Chimento
Marco Castelluccio
Margareta Eliza Balazs
Nicolas Silva
Brian Birtles
Cameron McCormack
CYBAI
Hiroyuki Ikezoe
Nicholas Nethercote
Ting-Yu Lin
Markus Stange
JW Wang
Bogdan Tara