When using the inplace editor, clicking on an autocomplete suggestion
no longer triggers apply() and no longer calls the done() callback.
This way the inplace editor behavas similarly when using the keyboard
and when using the mouse.
Unfortunately, this test is frequently reporting the doc_steady_allocation.html
test tab window as leaking. Let's disable it for now, and re-enable it along
with the other leaky tests in bug 1219554.
We need this package to build psutil and other Python packages with C
extensions.
Fedora 23 offers Python 3 as the default package and the package name
changed from python-devel to python2-devel. Fedora 22 does appear to
support python2-devel as an alias. So we use the same name everywhere.
DONTBUILD (NPOTB)
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
Using nargs='*' in conjunction with nargs=REMAINDER creates an ambiguity when
the argument using nargs='*' is optional, it is not specified, and the user
intends their arguments to be interpreted as "extra" arguments. This commit
removes the nargs=REMAINDER argument for mach_try, and implements its most
common users from trychooser as a set of regular arguments to echo to
generated try syntax.
MozReview-Commit-ID: FOuDZxUfHu9
This will run the SpiderMonkey promise jobs more or less the same way that we
run Promise jobs right now, including using a Web IDL callback for the actual
invocation.
nsWrapperCache expects the object it stores to have an ObjectMoved op that will
notify the wrapper cache when the object is moved. SpiderMonkey promises don't
have a way to do this.
The XPCConvert changes are needed to allow code that passes around Promise
objects as nsISupports to continue working instead of ending up with
double-wrapped nsISupports (XPCWrappedNative for an nsISupports XPCWrappedJS)
around the SpiderMonkey Promise.
This patch introduces a fake IDL interface just to get the benefits of
cycle collection for the JS-to-C++ link we now need for PromiseNativeHandler
(because the SpiderMonkey Promise somehow needs to point to the
PromiseNativeHandler). Now in practice a bunch of our PromiseNativeHandlers
are not cycle collected. That kinda freaks me out, but spot-checking a few
suggests they do not in fact leak (either because they don't form cycles or
because the Promise they're observing always settles and then releases them).
Either way, that's a problem that exists with or without this patch...
This is the one part of this set of patches that is actually a substantive change
even without SPIDERMONKEY_PROMISE defined. This is being done because I don't
want to create ResolveInternal/RejectInternal methods on dom::Promise in the
new world.
In practice, the difference between MaybeResolve/Reject and
ResolveInternal/RejectInternal is that the former will do nothing if the
Promise is "resolved" in terms of spec terminology: either settled or locked in
to track another Promise. A resolved but still pending Promise can still get
fulfilled (what we call ResolveInternal) or rejected when the promise it's
tracking settles.
So the difference only matters if PromiseWorkerProxy can be working with a
"resolved" Promise (in which case what it's doing now would settle it, while
what I'm switching to would not). But I don't believe PromiseWorkerProxy ever
points to a "resolved" Promise.
These are basically the minimal changes needed to make PromiseDebugging compile
in the new world. It will NOT function correctly (see the XXX comments); Till
will be fixing it up more in bug 911216 as he transitions the relevant bits in
our devtools to work on top of SpiderMonkey promises.
The idea is to not define a "Promise" property on the global and not generate
any of the methods, since SpiderMonkey will implement all of those, but to keep
some of the conversion to/from JS logic and the IDL parser validation bits that
we have right now. Once we can assume SPIDERMONKEY_PROMISE we can probably
change how the "Promise" identifier is handled by the IDL parser and how the
resulting type is handled by codegen, but for now we're aiming for minimal
changes.
This will perform a single HTTP request that completes in <1s. Contrast
with before when we performed multiple HTTP requests and the process
took several seconds.
DONTBUILD (NPOTB)
MozReview-Commit-ID: DjX3LBdSOIk
They were disabled in bug 657569 because of a miscompilation from MSVC,
but back then, we were using one of 2005, 2008 or 2010 (not entirely
sure which). Even if it was the latter, there has been two releases of
MSVC since, if stopping at the one we're currently using.
This patch reverts the "measure-in-advance" approach added in part 1 of bug
1050108 -- because that doesn't interact well with DMD -- and adds locking to
avoid races between the url-classifier thread and the main thread.
