Make sure origins had been initialized in Maintenance::DirectoryWork before getting
QuotaObject. It's possible that DatabaseMaintenance::Run before origins initialized.
This is a follow-up patch for bug 1392970. Since we only set CustomElementDefinition on a custom element
which is "custom", we could add more assertion to ensure that.
MozReview-Commit-ID: 2sLP53bAYVV
--HG--
extra : rebase_source : 523761aa7312ddfaaf91f79e39c44ddce5cf9335
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
In some circumstances it is possible to sample a timed element in the active
state with a time that precedes is current interval.
One possible sequence of steps leading to this situation is as follows:
1. A timed element (e.g. <set>, <animate>) with a non-zero begin time is the
child of <svg> element A (its "time container") but has yet to be sampled.
2. In order to resolve its initial interval, the timed element registers a
startup milestone with its time container at time 0.
3. However, before the sample is performed where the timed element's initial
current interval is resolved, <svg> element A is detached from the document
tree.
4. The timed element is then attached to a different <svg> element B that has
a current time greater than the begin time of the timed element and less than
that of <svg> element A.
5. Since the timed element is still in its startup state it registers its
startup milestone again, this time with its new time container, i.e. <svg>
element B.
6. A tick occurs or the document has its style flushed such that a sample is
performed.
This includes running the milestone sample which causes the timed element to
resolve its initial current interval. Furthermore the subsequent regular
sample of the timed element causes it to transition into its active state
because the current time of <svg> element B is greater than the begin time of
the timed element.
7. <svg> element A is re-attached to the document.
8. When we go to run the next sample, we iterate through all time containers
associated with the document's animation controller which includes both <svg>
element A, and <svg> element B.
9. <svg> element A renders up its 0 milestone from step (2) since it has yet to
run it. It converts this to parent time, i.e. the time space of the animation
controller, which will be zero or less depending on the current time of <svg>
element A when it was re-attached.
10. Since the milestone from <svg> element A will be the earliest milestone
time, it will be used as the next milestone sample time.
11. The timed element is then sampled using this time, but first it is converted
to a time in the time space of the timed element's time container, which is
now <svg> element B.
As a result of this conversion, the sample time may end up being *before*
the beginning of the timed element's current interval. Since timed elements
never expect the time to go backwards an assertion fails when it detects
that it is active, but is being sampled before its current interval.
For this particular case, ignoring the "early" sample seems to be the most
appropriate action.
More generally, however, we can anticipate other cases similar to this where
milestones are registered that cause the sample time to temporarily go
backwards. A quick audit of nsSMILTimedElement::DoSampleAt suggests that, with
the code changes from this patch, that is probably ok.
As an alternative we could, perhaps, try to drop and re-create all milestones
when time containers are re-attached to the document tree but that would add
more complexity and would not necessarily cover other similar cases of this
situation.
I have verified that the crashtest included in this changeset fails without the
code changes also in this changeset.
MozReview-Commit-ID: KKGYRayNkpo
--HG--
extra : rebase_source : 832d4b357a2a2fe07abf9eab3a6046599aff3ef5
There are no reliable steps to make this happen but it appears to have happened
at least twice during fuzzing. As a result, it doesn't matter too much what the
behavior here is as long as we don't crash.
MozReview-Commit-ID: 4gdiBL2wngU
--HG--
extra : rebase_source : 54afce721f8b59c2ad038e0c2222f64e71a9b917
When server responses a field value with null, we have to ignore it, or we fail to SetRequestMethod for the http channel.
MozReview-Commit-ID: EW9NHMy22Fc
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
The test case uses double intervals to make sure there is enough time to wait for the scroll event before continuing the testing. However, it doesn't work while the first timeout is delayed and the second one isn't. Tweaked the test case to start the second timer when the first one timeout.
MozReview-Commit-ID: gvhtIpzauE
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
This also brings in and convert some utilities we have in Gecko, that will ease
porting more tests.
MozReview-Commit-ID: 2yPZQO504kH
--HG--
rename : dom/media/webaudio/test/test_analyserNodeOutput.html => testing/web-platform/tests/webaudio/the-audio-api/the-analysernode-interface/test-analyser-output.html
extra : rebase_source : 0a9c9c336b1b53120010a081da131c76f103a838
The delegate property of NSSpeechSynthesizer doesn't seem to add refcount from 10.13, so we have to keep SpeechDelegate object until speech is finished.
MozReview-Commit-ID: EVtMOPytkjR
--HG--
extra : rebase_source : f2a6d97942c19990a16dd68555328ed36280eb4a
Most cases where the pointer is stored into an already-declared variable can
trivially be changed to MakeNotNull<T*>, as the NotNull raw pointer will end
up in a smart pointer.
In RAII cases, the target type can be specified (e.g.:
`MakeNotNull<RefPtr<imgFrame>>)`), in which case the variable type may just be
`auto`, similar to the common use of MakeUnique.
Except when the target type is a base pointer, in which case it must be
specified in the declaration.
MozReview-Commit-ID: BYaSsvMhiDi
--HG--
extra : rebase_source : 8fe6f2aeaff5f515b7af2276c439004fa3a1f3ab
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
