For signing, pykey.py delegates to 3rd party libraries. One of these libraries
expects hash algorithms to be specified in the form "SHA-256" whereas the other
expects "sha256". Consumers of pykey shouldn't need to be aware of this detail.
This patch introduces constants HASH_SHA1, HASH_SHA256, etc. and changes pykey
to determine which string literals to use itself.
MozReview-Commit-ID: 27laM2uXMwJ
--HG--
extra : rebase_source : 9b74f486f7535671fd26c59e3e9cc3b4459f15e0
Similar to the other unload and load events during a page load,
the hashchange event should only be handled if the event's target
document is the current window.
MozReview-Commit-ID: F1LMBh5Cy4A
--HG--
extra : rebase_source : 668fd6946067989e7e732b24baf6de2e85541f21
originalTarget seems to be outdated and not used anymore for each
navigation related event. But target is, and as such handleEvent
has to make use of that instead.
MozReview-Commit-ID: AN2H1PbCt7A
--HG--
extra : rebase_source : fbead2b5b802454f0e288fb9696db5d422e46b50
This is a re-land of 9900d421e24e, which was backed out.
r=qdot,haik
MozReview-Commit-ID: FjugGCVWS8T
--HG--
extra : rebase_source : 7913a74a7bac9df09f8fc8e923384b5ac2569400
Add two tests to testInputConnection that record the sequence of
composition events during editing, and check that the sequence is what
we expected.
The first test makes sure that we reuse the current composition on the
Gecko side when setting composing text; otherwise the Facebook comment
box behaves incorrectly.
The second test makes sure that we can move the cursor inside the
current composition, to fix this particular bug.
* Include the type of the editor (input, textarea, contentEditable,
designMode) in BasicInputConnectionTest, so we can work around the
differences in behavior among the different editor types.
* Add timestamps to key events, because lack of timestamps was
triggering a crash when running testInputConnection.
Update the composition when setting/removing spans, so that we update
the selection/cursor during a composition. However, we must limit any
updating to the current composition only (as indicated by the
keep-current-composition flag), because the Facebook comment box behaves
incorrectly if we repeatedly start and end new compositions.
When we just had CycleCollectedJSContext (and no CycleCollectedJSRuntime) a
weird thing happened at shutdown:
1. We would call JS_DestroyContext from ~CycleCollectedJSContext. By that time,
the ~XPCJSContext destructor had already finished.
2. Destroying the context runs a final GC. That GC would call back into various
GC callbacks, such as TraceBlackJS and TraceGrayJS.
3. These callbacks would do a virtual method call:
http://searchfox.org/mozilla-central/rev/876c7dd30586f9c6f9c99ef7444f2d73c7acfe7c/xpcom/base/CycleCollectedJSRuntime.cpp#791
4. Normally this method call would call into
XPCContext::TraceNativeBlackRoots. However, C++ changes the vtable for an
object during destruction. So we would only call CycleCollectedJSContext's
version of TraceNativeBlackRoots, which is empty. So we never traced anything.
When I moved this code into the runtime, we actually do call into
XPCJSRuntime::TraceNativeBlackRoots at that time. So the behavior changed, and
that was causing crashes once I nulled out the TLS as you asked. So I removed
these callbacks for the last GC.
MozReview-Commit-ID: 3do13bjpwQj
This patch keeps a list of all the cooperatively scheduled contexts that are
linked to a runtime. In places where we need to iterate over all contexts (for
GC, specifically), it iterates over the list.
MozReview-Commit-ID: 3pKJX78f2l0
This field assumes there is one XPCJSContext globally (i.e., per nsXPConnect
instance). This patch eliminates the field by using different paths to
reach the context.
MozReview-Commit-ID: FjR6cTZ5QfZ
XPCJSContext::Get() now does a TLS lookup, which is a little more expensive
than looking up a global variable. This patch removes as many of the TLS
lookups as possible.
MozReview-Commit-ID: GsqzJn55Lya