SystemErrorReporter is the new unified error reporter for everything non-dom.
In particular, it's used by the SafeJSContext, which we'll be switching to
here shortly.
We need to stash it somewhere, because the shell-provided JSNatives need to
access it. This solution only works for script running in the scope of the
global we create. Butthat's fine here, because we only use it for load() and
quit(), which only exist in the scope of that global.
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.
========
https://hg.mozilla.org/integration/gaia-central/rev/c59267134f80
Author: Corey Frang <gnarf37@gmail.com>
Desc: Followup tests commit for Bug 883822 / d17ada1 - r=rwaldron a=npotb
* Removes some useless tests and replaces them with tests that actually test d17ada1
========
https://hg.mozilla.org/integration/gaia-central/rev/4f7140e2e3a9
Author: Fabien Cazenave <fabien@cazenave.cc>
Desc: Bug 883822: [SMS] focus the Compose area when started as an activity - r=gnarf
When the Compose screen is triggered by an activity (e.g. when clicking on a message icon from the call log), recipients are inserted and the onscreen keyboard is triggered. The problem is, the focus is set within a recipient block, not in the input itself: thus, the onscreen keyboard doesn’t disappear when the back button is hit.
A possible fix would have been to focus the recipient input rather than the recipient block, but it’s simpler to focus the Compose area instead (and that’s one less tap for the user). That’s what this simple patch does.
Closes gh-10979
========
https://hg.mozilla.org/integration/gaia-central/rev/6b34842a2150
Author: James Lal <james@lightsofapollo.com>
Desc: Merge pull request #11016 from ganesh7/887698
Bug 887698 - [OTA] [Data Migration] [Calendar] Calendar blank screen aft...
========
https://hg.mozilla.org/integration/gaia-central/rev/31a971cb141c
Author: gghosh <ganeshghosh@gmail.com>
Desc: Bug 887698 - [OTA] [Data Migration] [Calendar] Calendar blank screen after update from v1.0.1 to v1.1.0
