This populates $OBJDIR/dist/host/bin as part of |mach artifact install|.
Conceptually, the mar and mbsdiff utilities should be grouped (in the
same way that the test-related binaries are grouped). However, it's
difficult to achieve that with the current structure of the code, so
this fetches mar and mbsdiff and produces $HASH-mar.processed.jar and
$HASH-mbsdiff.processed.jar files.
MozReview-Commit-ID: 3ks5xsUEKp5
--HG--
extra : rebase_source : 5fcf186decc95537cbaa90ffedb86774eab050d2
GetThreadContext() returns a context pointing to its own frame when it
gets called with the current thread handle. That frame can go away after
it returns. This patch instead uses RtlCaptureContext(), which captures
the context of its caller, when walking the current thread.
MozReview-Commit-ID: 3TAatDc9BLh
--HG--
extra : rebase_source : d5d88f0a9fa07da5b31f27c51c78ee2bfb527a8e
GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : 0e72e8f6196c8079086ca697b9a121c6987ef43e
This inlines and simplifies the call to XPCOMUtils._getFactory,
because otherwise passing PdfStreamConverter appears to resolve it
immediately, loading the JSM. (The stream converter prototype does not
have a property _xpcom_factory, so there's no need for the check.)
Once that is done, we can just lazily load the stream converter JSM to
keep it from being loaded on startup.
This patch also checks that the stream converter is not loaded at
startup in the main process or the content process, and that PdfJs.jsm
is not loaded at startup in the content process. It needs to be loaded
in the main process to watch for some prefs.
MozReview-Commit-ID: EA0pSgs4AWH
--HG--
extra : rebase_source : ebc99d6dc5c00cd45192ec0580f887d8970d9dd0
As with the last patch, the factory is only used for a single class,
so move the constants closer to where they are used. This will allow
us to register the stream converter without loading the stream
converter JSM.
MozReview-Commit-ID: DRKVtYQOs2J
--HG--
extra : rebase_source : 09b84838ee31e18db1c70d75d091d3c9f6d95297
Factory is only ever passed PdfStreamConverter, so specialize the
registration method and rename the class. Also, classID2 is always
non-null for PdfStreamConverter, so drop the check.
MozReview-Commit-ID: Ts295QTmrm
--HG--
extra : rebase_source : 0a944fec22df5fb243fbfa65aa4eba91a63e2793
This patch fixes an intermittent failure in the pdf.js browser chrome
Mochitests, where it runs code inside PdfStreamConverter.jsm and gets
the error "TypeError: getBoolPref is not a function". getBoolPref is a
top-level function inside the JSM.
I couldn't reproduce this, but I suspect that defineModuleGetter would
run, and give us a reference to the PdfStreamConverter converter
object in the JSM. Eventually, we would unload this JSM, and somehow
clear out the top level scope. However, the registration JSM still had
its reference to the Converter object. Eventually we would try to
convert again, using the old JSM, but the scope was cleared out, so it
couldn't find the top level function in the converter JSM.
While I could probably work around this somehow by clearing the global
reference to the old JSM and setting up a new thunk, I think it is
better to simply not do the unload. Unloading a JSM is a weird
operation that we don't use much, and I think the only drawback for
not doing so is that a user that disables PDF.js will continue using a
little more memory during that session.
MozReview-Commit-ID: Lx3QZza5qCM
--HG--
extra : rebase_source : cbcf5bc285fa91b5631d388f7ac45fbabaccd34a
The goal of these patches is to load neither PdfJs.jsm nor
PdfStreamConverter.jsm in a content process unless the user is viewing
a PDF, to save memory.
This first patch creates a small stub JSM to do the stream
registration, and calls it directly in the content process, avoiding
one way we load PdfJs.jsm. The existing registration methods are kept
for the main process.
MozReview-Commit-ID: 5GH8tjHXfLb
--HG--
extra : rebase_source : f89b184bf96f2a55c1ee688538f2d5965ffdc660
Before this patch, we exposed a few interfaces that revolved around mapping a
name to a specific PKCS#11 module, slot, or token. These APIs were all either
problematic and/or unnecessary. In theory there could be two tokens in different
modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed
to return what the consumer expected it to. In general, these APIs were used by
front-end code to go from a handle on the specific object in question to a
string identifier and then back to a handle on the object. This was unnecessary
- we can just retain the original handle.
MozReview-Commit-ID: IbqLbV4wceA
--HG--
extra : rebase_source : 05d39afd6bed0aa5e7694e1c79baf836edc03214
Creating these promises from ext-toolkit.js was always dicey since that
script is loaded asynchronously during startup. This should ensure that
the startup promises are reliably created early enough in startup.
MozReview-Commit-ID: A0V7iCOFNI8
--HG--
extra : rebase_source : 5c6562dc2c91f03ce1062a69080ba04d742fbc22
Instead, return an error up to the caller, who can return an IPC error, which
will kill the child. This is significantly friendlier to fuzzing.
MozReview-Commit-ID: C67xSqUeN1i
The methods where it's used don't run from reflow (they're image notifications
that run off runnables and such), so should be an idempotent change.
MozReview-Commit-ID: LdmSOcKDdw1
--HG--
extra : rebase_source : 273ed355a9bfb8aefdf92a85802a47ac39373d19
