mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
Upgrade the test names from 3.0/3_0 to 2.1/2_1, consistent with the changes
made in part 1.
--HG--
rename : dom/quota/test/unit/test_version3_0upgrade.js => dom/quota/test/unit/test_version2_1upgrade.js
rename : dom/quota/test/unit/version3_0upgrade_profile.zip => dom/quota/test/unit/version2_1upgrade_profile.zip
extra : rebase_source : f0b33f52d9247ed4b14a2debc22551f98b211741
extra : source : efc62fb7fa68968335c605cf54f1d94631bc3b33
Alter 57 and 58 DOM Cache API to use an on-disk schema version of 25 again,
as was used prior to the landing of bug 1290481 that bumped the disk schema
version to 26. Patched versions will recognize this internally as schema 27
based on the presence of the column introduced by the 26 upgrade.
--HG--
extra : rebase_source : 03d6e361ef71de03e99bd27bc27a95ed65ecb846
extra : source : 523debab77daab9f69ca9ea19412c655e6d1e02f
To improve the Firefox 57 to 56 downgrade scenario, have 57 and 58
re-number the version 3.0 schema introduced by bug 1290481 to
version 2.1. Firefox 56's Quota Manager will recognize the minor
schema version and accept the schema from the future.
--HG--
extra : rebase_source : c2458e380966e4f1ec60a6df5f01135231f308fe
extra : source : e895c35e9b4e9dbc6849d40d644af97c028fffcf
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
CreateDecoder is the only caller of InstantiateDecoder, and all CreateDecoder
does is call InstantiateDecoder.
MozReview-Commit-ID: KwwL2el8L4x
--HG--
extra : rebase_source : bff225558fd2de535c2cb010eb35b95c6d9469e5
We can use Selection directly instead of nsISelection. It means that we don't need QI for nsISelectionPrivate. So IMEContentObserver should hold Selection instead if nsISelection.
MozReview-Commit-ID: 4jp9wWHRHRd
--HG--
extra : rebase_source : 9f4792cf75555b5aafdacfd8f137e68d9da86e04
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
Per the CSP specification, content injected by extensions is meant to be
exempt from page CSP. This patch takes care of the most common case of content
injected by extension content scripts, which always have expanded principals
which inherit from the page principal.
In a follow-up, we'll probably need to extend the exemption to stylesheet
content loaded by extension codebase principals.
MozReview-Commit-ID: GlY887QAb5V
--HG--
extra : rebase_source : 1371b4e4e7f330b7f7721d4aa169fcb52a7622d0
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
This avoids the need for numerous 8-to-16-bit and 16-to-8-bit string
conversions.
The patch also introduces a higher-order macro, FOR_EACH_CSP_KEYWORD, which
defines all the stuff about the keywords in a single place and makes the code
nicer.
--HG--
extra : rebase_source : b0f655546aa397749bb18dc7d6d27fbc12fe8fca
This is similar to Services.tm.idleDispatchToMainThread, but provides an
IdleDeadline argument to its callbacks, the same way that
Window.requestIdleCallback does.
The IdleDeadline argument was necessary for my first attempt at this bug. It's
not necessary for the current version, but I suspect it will be useful in
other areas, and it also avoids some XPConnect overhead, so it's probably
worth keeping.
MozReview-Commit-ID: FtrbNkE7Vz5
--HG--
extra : rebase_source : d28973641e914c8d180f66125669aabc29ab857f
Since the presence of an entry with a null selector is different for Gecko and
Servo, this seemed easier, and mimics nsLayoutStyleSheetCache.
Also, this is going away soon anyway as soon as I get to implement the rest of
the methods for stylo.
MozReview-Commit-ID: DtHJbw8C0GX
--HG--
extra : rebase_source : dd450a6972054971eba8bba5bb022b74d07c2a0b
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
ChildPrivileges is a leftover from the B2G process model; it's now
mostly unused, except for the Windows sandbox using it to carry whether
a content process has file:/// access.
In general, when sandboxing needs to interact with process launch, the
inputs are some subset of: the GeckoProcessType, the subtype if content,
various prefs and even GPU configuration; and the resulting launch
adjustments are platform-specific. And on some platforms (e.g., OS X)
it's all done after launch. So a simple enum used cross-platform isn't
a good fit.
MozReview-Commit-ID: K31OHOpJzla
--HG--
extra : rebase_source : 3928b44eb86cd076bcac7897536590555237b76b
Reorder WebAuthentication.webidl to match the ordering of the IDL index in
the Web Authentication spec. No normative changes.
MozReview-Commit-ID: 7qPE60Qh7Ly
--HG--
extra : rebase_source : 18f18a85c013528bf9b2ec84165f7a32a134c3d7
This covers these renames:
* In CollectedClientData, hashAlg => hashAlgorithm
* In CollectedClientData, tokenBinding => tokenBindingId
* In MakePublicKeyCredentialOptions, parameters => pubKeyCredParams
* In MakePublicKeyCredentialOptions, excludeList => excludeCredentials
* In PublicKeyCredentialRequestOptions, allowList => allowCredentials
* Transport (WebAuthnTransport in Gecko) => AuthenticatorTransport
MozReview-Commit-ID: 3FdRnkosy83
--HG--
extra : rebase_source : 22f124c781b03837ad0cd4be4edf34527e3b9d38
This covers these renames:
* In PublicKeyCredentialParameters, algorithm => alg
* MakeCredentialOptions => MakePublicKeyCredentialOptions
* PublicKeyCredentialEntity => PublicKeyCredentialRpEntity
* Attachment => AuthenticatorAttachment
It sets a default excludeList and allowList for the make / get options.
It adds the method isPlatformAuthenticatorAvailable which is incomplete and
not callable, to be completed in Bug 1406468.
Adds type PublicKeyCredentialRpEntity.
Adds "userId" to AuthenticatorAssertionResponse.
Adds "id" as a buffer source to PublicKeyCredentialUserEntity and as a
DOMString to PublicKeyCredentialRpEntity, refactoring out the "id" field
from the parent PublicKeyCredentialEntity.
It also adds a simple enforcement per spec 4.4.3 "User Account Parameters for
Credential Generation" that the new user ID buffer, if set, be no more than
64 bytes long. I mostly added it here so I could adjust the tests all at once
in this commit.
MozReview-Commit-ID: IHUdGVoWocq
--HG--
extra : rebase_source : bc1793f74700b2785d2bf2099c0dba068f717a59
WebAuthn has added a flag UV to indicate the user was biometrically verified. We
have to make sure not to set that flag for U2F. Turns out we already do that,
but let's add the constant and such.
Ref: https://w3c.github.io/webauthn/#authenticator-data
MozReview-Commit-ID: 6Qtjdkverls
--HG--
extra : rebase_source : 660348596b917d8f461b19298e01dbe19410b63f
There are currently some corner cases where channels that are eventually
loaded into documents (mainly <img src="data:image/svg+xml,") can inherit
expanded principals from a caller. Since documents aren't allowed to have
expanded principals, this causes crashes.
This patch is a short term workaround for the issue, until we have a longer
term solution that prevents the channels from inheriting the expanded
principals to begin with.
MozReview-Commit-ID: JwqqtVynLjj
--HG--
extra : rebase_source : 23199517414428924e9c78629ac794b54bd23c52
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : 44ea3d0eb292e5c285d0aa4e10eefa41f20beed7
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 0334b71534cfaccaf1d8985d827fe4e5d5bf0e9f
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : b1dc3193d839ef3776195901339fae24f328207b
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
I don't know whether or not another zero initial AudioChunk member value
makes initialization more efficient, but zero for silence is more intuitive
for humans.
MozReview-Commit-ID: JEYv65btMul
--HG--
extra : rebase_source : 3089362ce4773da91c7139a3127e1491cbcf1dc5
This avoids any risk of undefined behavior when evaluating uninitialized
members, during copies for example, and makes it safe to test mBufferFormat
when null.
MozReview-Commit-ID: IMAyZ1CSHbk
--HG--
extra : rebase_source : b02431634732cf63d6fe9ede5eb1400a2baa6308
The imgLoader code consistently uses the term 'loadingPrincipal' for the
principal that is called the triggeringPrincipal everywhere else it's used.
This is confusing, and since we need to make changes to how those values are
determined, it should be fixed beforehand.
MozReview-Commit-ID: 8CTHwayzcaD
--HG--
extra : rebase_source : d4405b0ecfe1c8dfb9bfdf61fe6ed6cfb180ba83
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
Once we call DoneAddingChildren, random code of various sorts will run, which
can flush our notification state. If that happens before we've notified on our
kids, but after we've popped the element we're closing off the element stack,
we will fail to ever notify on the kids.
MozReview-Commit-ID: Ei7v5OobX8R
Using a copy constructor here means that reallocating hashtables
containing nsSMILCompositor does a bunch of unnecessary work; we can use
a move constructor to avoid a lot of that unnecessary work.
Defining Singleton() in the declaration of nsSMILNullType implicitly
sticks an "inline" on the function, which is not what we want: inlining
it spreads around a lot of static initialization code. Providing an
out-of-line definition is much better in terms of code size.
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : a2661dce1ac191fdf098e631cd7878f0215643d5
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : rebase_source : f89bd84b130273ff734471619485d5f12a83006d
extra : source : 9b63f9eaa250ebe7259cc7fab709aac00858aaf6
This commit removes:
* layout.css.style-attr-with-xml-base.disabled pref
* deprecation XMLBaseAttributeForStyleAttr
* code path for getting base URI of style attr considering xml:base
MozReview-Commit-ID: 1w96eqhHPab
--HG--
extra : rebase_source : 95e33da698ce0cfc9a44de8bc0d63c3fa4634644
This is unnecessary work but simpler than adding a path to, or refactoring, AudioCallbackDriver::DataCallback.
MozReview-Commit-ID: GLNoBqxEuwz
--HG--
extra : rebase_source : b5ef6b2e1506e68d41b22ad557968d70214fbd9f
Owning the monitor is not sufficient for consistent state if state can be
accessed without the monitor.
The requirements for SetCurrentDriver() are tighted to require both the
monitor and correct thread, as CurrentDriver() can be called either with the
monitor or on the graph thread.
MozReview-Commit-ID: 90q7Pfa8jxn
--HG--
extra : rebase_source : 6cbcc334dc2bd355d2e9afdebda45a9624edda4b
This also permits setting mDriver to null after mDetectedNotRunning, which is
useful for fixing bug 1406830.
MozReview-Commit-ID: EEgAxqPQPRI
--HG--
extra : rebase_source : 56e1583a0090e683e92463536637d0f1460cb727
mLifecycleState is always > LIFECYCLE_RUNNING when mDetectedNotRunning
MozReview-Commit-ID: Ds6ybTv4miA
--HG--
extra : rebase_source : 71aea6693026dc919ea6d2096f55152ae12bc58e
Accessing the graphic device driver from the parent process, should the drivers crash have serious consequences (the whole browser dies).
MozReview-Commit-ID: EXXRBnDobQw
--HG--
extra : rebase_source : d5609f1e088c7bbe92d6e46e66e1fb5538d5caac
This is needed since the pref will be sent with the first IPC message as soon
as the content process starts. Without this, it crashes on debug builds.
MozReview-Commit-ID: 3mGwEkaJF7n
--HG--
extra : rebase_source : 42f8d29bf9b74a42b08156ad07f262323b42c72b
MDSM doesn't reset the decoding pipeline of MFR when doing NextFrameSeek and
therefore fails the assertion by requesting video data while MFR is still seeking.
We put the fix in the media element because it doesn't make sense to do
NextFrameSeek while another seek is already in action.
MozReview-Commit-ID: D6FSiNWHrLU
--HG--
extra : rebase_source : 7793fa32fb5fe3406f235aa43908a8a96202ee6c
Capturing |this| only if |self| needs to appear more than twice in a lambda.
MozReview-Commit-ID: 38iYDznjgBH
--HG--
extra : rebase_source : 9471fd4519c5c5be6e6e10eb11db8eeb041327d1
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.
However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.
The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.
This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".
The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().
MozReview-Commit-ID: BQOBpHHFMoD
--HG--
extra : rebase_source : e84a50a16a61d48553610cb7ea0863f09ba86c60
According to FFmpeg documentation, the out parameter is "set to size of parsed buffer or zero if not yet finished. " however this is only the case if no error occurred; otherwise it is left untouched.
We want the invalid content to generate a decoding error, so we set size to inputSize to ensure decoding failed later.
MozReview-Commit-ID: FZeiZUdUtLG
--HG--
extra : rebase_source : 2e81d730bacaea5bb968f704a36b403117dafcba
Every time a document is destroyed, we record whether MathML was enabled,
which is set to true when a MathML element was bound to the document.
'mathml.doc_count' will report how many such documents existed during a
session. It should be compared to MIXED_CONTENT_PAGE_LOAD, which counts the total number of all page loads.
MozReview-Commit-ID: Euf1apT2LhC
--HG--
extra : rebase_source : b8a55a4d8b59ddcb112aa85218c7b495c18b2627
Changes FrameLoader.print() WebIDL declaration to allow 3rd argument
(print progress listener) to be null or omitted.
This change allows tabs.saveAsPDF(), which calls FrameLoader.print()
with a null 3rd argument, to work correctly in Firefox 57.
MozReview-Commit-ID: AAHgPuMTvDe
--HG--
extra : rebase_source : 68a433b630970eda2cbe5c1661f3a100ad2e2020
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
MozReview-Commit-ID: DpAhmLH3uJ2
This is pretty much a straight-forward change except for a single thing, the
UpdateInsertionParent calls.
However, I cannot make any sense of them. They go through the inserted children
setting the insertion point, but then ClearInsertionPoints() is called.
ClearInsertionPoints calls XBLChildrenElement::ClearInsertedChildren, which sets
all the insertion points to null anyway.
Thus, I've removed that function completely.
MozReview-Commit-ID: 80daGQfLZrV
--HG--
extra : rebase_source : d52a37a60147ac11794c3cfe1aad5d202e9d2d9f
Andrea Marchesini
Alastor Wu
Tim Taubert
Sebastian Hengst
Andrew Sutherland
Dan Minor
Valentin Gosu
Thomas Nguyen
Phil Ringnalda
Jeff Gilbert
Brendan Dahl
Emilio Cobos Álvarez
Kris Maglione
JW Wang
Ethan Lin
Chris Pearce
Cameron McCormack
bechen@mozilla.com
Kearwood Gilbert
Boris Zbarsky
Makoto Kato
Randell Jesup
Joel Maher
David Major
Nicholas Nethercote
Dan Banner
Kyle Machulis
Steve Fink
Edgar Chen
sotaro
Xidorn Quan
Christoph Diehl
Ryan VanderMeulen
Ben Kelly
Dragana Damjanovic
Shawn Huang
Jason Orendorff
Catalin Badea
Gerald Squelart
Mike Hommey
Jed Davis
J.C. Jones
Luca Greco
Tom Ritter
Luke Wagner
Shane Caraveo
evilpies@gmail.com
Jean-Yves Avenard
James Cheng
Hiroyuki Ikezoe
Robert Longson
Karl Tomlinson
Stone Shih
Tobias Schneider
Ehsan Akhgari
Jorg K
Nathan Froyd
Peter Van der Beken
Tom Tung
cku
Andrew Osmond
Chih-Yi Leu
Nevin Chen
Alex Chronopoulos
John Lin
Jan-Ivar Bruaroey
Andreas Pehrson
Masatoshi Kimura
Alessio Placitelli
Attila Craciun
Brian Birtles
Alfredo.Yang
dw-dev
Thomas Wisniewski
Kartikaya Gupta
ZER0