They're useless now, provided we remove the hack to not traverse XBL-bound
elements on initial styling.
This also allows us to get rid of the fallback case.
MozReview-Commit-ID: AvBVdyF1wb6
If the element has no data, it's pointless to reconstruct frames on it, or post
a reconstruct. There's no need to particularly force to have data in this case.
MozReview-Commit-ID: Lo24XQfLN0j
We not only need to care about children getting inserted in the flat tree, but
also about children moving _out_ of the flat tree.
In particular, as of right now we may leave stale data on elements when they
disappear from the flattened tree.
We're lucky enough that in 99% of the situations we enter in[1] and that clears
all the stuff, including servo data. But my assertions for bug 1414999 caught
the template / observes case.
Thus, just clear the whole bound element subtree data, and restyle it in the
end, no need for StyleNewChildren. This matches what we do for shadow DOM
(though in the shadow DOM case we do it async in DestroyFramesForAndRestyle).
[1]: https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/dom/xbl/nsXBLBinding.cpp#368
MozReview-Commit-ID: 69A0aR0AFfU
They're useless now, provided we remove the hack to not traverse XBL-bound
elements on initial styling.
Bug: 1418456
Reviewed-by: heycam
MozReview-Commit-ID: AvBVdyF1wb6
Source-Repo: https://github.com/servo/servo
Source-Revision: e4cfff8364cebd0ae2236cc8c39ba93072b35148
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b9ae9d359687ae32609a11d9ad5e8457c548e941
Currently we run the risk of missing MediaManager::OnNavigation() at shutdown in
some cases. When it happens, cleanup of window listeners is delayed to
MediaManager::Shutdown().
Triggering window listener shutdown through the destructor doesn't work when the
destructor is invoked by WindowTable::Clear(), as clearing out the
window listener's SourceListeners will trigger a call back into
WindowTable::Remove() to remove the now empty window listener.
This is not allowed by the hash table implementation.
This patch fixes this by changing strategy from cleanup-in-dtor to explicit-cleanup-before-dtor and making a non-clean state in the dtor an error.
MozReview-Commit-ID: C9FryVlv28d
--HG--
extra : rebase_source : 55ccf96b15eb3261d5176364e6952f51415bc668
This delays setting sInShutdown (renamed to sHasShutdown for better semantics)
until all that remains of shutdown is to shut down the media thread.
From JS this is no change as JS cannot run until Shutdown() is done.
The difference is that we let members and still-active listeners get destroyed
and cause any members that are media-thread only (in this case devices), to shut
down before the thread goes away.
MozReview-Commit-ID: 5NTWwh8Umn8
--HG--
extra : rebase_source : f6b508abc95434f027a6544fdac53949138764da
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : b88ccf98bc2a41aac007d79060424eaa2c2aca88
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902
The "current URL" in the spec:
https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-currentsrc
maps to imgIRequest.URI, not currentURI.
Rename imgIRequest.currentURI to finalURI to prevent such confusion.
MozReview-Commit-ID: CjBh2V4z8K9
--HG--
extra : rebase_source : d3047aed22f116ff9a74099b646a84e597388673
Called Option::unwrap() on a None value is not a helpful crash message.
This will hopefully help figure out what is causing bug 1418856.
Source-Repo: https://github.com/servo/servo
Source-Revision: af6c2f93b9ff91f4c3e5758d9b27173e49928bed
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 79fcf95fafaa207f4ce7bdfa08b256d388e1aa47
Increased the dialog width and align html button styles with XUL button styles (padding, min-width) in common stylesheets.
MozReview-Commit-ID: Czzu0Ar6JfP
--HG--
extra : rebase_source : 3f9206ac21f0b533952c0ad5c898cfdf0e3a23ea
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
