XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
This adds a Component type to the mozbuild.mozpack package manifest
parser, and teaches the packager to accept components of the form
[name destdir="dir"]. Then we update the Android package manifest and
simplify the packager code.
I would have liked to make the packager put mozglue.so and
MOZ_CHILD_PROCESS_NAME in lib/$(ABI_DIR) directly, but this turned out
to be awkward. Since MOZ_CHILD_PROCESS_NAME needs to have lib/ in its
name to load successfully on Android, we would have to add notation in
package manifests to install bin/lib/*plugin-container* to
lib/$(ABI_DIR)/*plugin-container*.
The issue is that in INNER_UNMAKE_PACKAGE I was deleting
assets/omni.ja, which is needed in INNER_MAKE_PACKAGE. This breaks
language repacks. This fix should at least allow repacks to proceed
further.
* Add a test-only setter to the center-item XBL binding
* add a head.js function to remove plugin permissions for use in cleanup functions
* browser_pluginnotification.js - lots of fixes for the core feature tests
* Alter test_bug751809 not to assume that clicking the page overlay will directly activate the plugin
* Alter browser_CTP_plugins.js because disabled plugins now do show up in the plugin doorhanger
* remove browser_CTPScriptPlugin.js and supporting files because we no longer auto-pop based on scripting
* fix browser_CTP_drag_drop.js so that active plugins still show the doorhanger icon, and other fixup
* fix browser_bug743421.js to expect the doorhanger all the time and activate it correctly
* fix browser_bug752516.js to check for doorhanger activation instead of plugin activation
* remove browser_bug818009.js and supporting files because they are testing something that no longer exists
* alter browser_bug820497.js so that it shows the popup notification before checking .centerActions, since we populate that data lazily now
* browser_plugins_added_dynamically.js: remove the "activate all" tests which are no longer relevant and fix the rest to match the new doorhanger structure.
This incorporates follow-ups including: rename the debug key; check if
key alias exists rather than just testing for keystore existence; set
$(AIDL).
Renaming the debug key works around an un-confirmed JDK bug in
jarsigner, where '-debug' and 'debug' compare the same.
