зеркало из https://github.com/mozilla/gecko-dev.git
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
8db444c416
There are several cases to consider in terms of where exceptions might come from here: 1) We could have an exception on the JSContext already when we set up the AutoEntryScript. In practice this does not happen, and once this change is made we will add an assert to that effect in AutoJSAPI::InitInternal. See bug 1112920. 2) We could have an exception thrown by the XPCCallContext constructor, but it never does that when initialized, as here, without a JSObject*. 3) We can have an exception thrown by CallMethod itself, if the callee method wants a JSContext or optional argc. This patch switches that to using CheckForException, which means it will behave exactly like exceptions thrown from the actual implementation of the method we're calling in terms of how it's reported and whether it's rethrown to callers, if any. 4) We can have exceptions thrown various places (e.g. during argument and retval/outparam conversions) after this point, but those are all under the scope of the AutoScriptEvaluate, whose destructor will restore the JSContext state to whatever it was when the AutoScriptEvaluate was created. Since the AutoScriptEvaluate goes out of scope before the AutoEntryScript does, there will be no dangling exception on the JSContext at that point. 5) We can have exceptions thrown by the actual method call. Those are reported, as needed, via CheckForException, and will continue to be so reported. So in general there are two behavior changes here: * We now treat the "callee wants JSContext or argc" case as the same as an exception from the callee, which is not what we used to do. * If the object we're calling comes from an inner window whose outer window has been torn down, we will now correctly report the exception against that inner window. Before this patch, what happend is that we would init the AutoEntryScript with the inner window, but FindJSContext would not find an nsIScriptContext on it (since its outer has been torn down), so we would use the safe JS context. Then in xpc::SystemErrorReporter we would check for a window associated with the JSContext, not find one, check for an addon sandbox current compartment, see we're not in one, and then use the privileged junk scope for its error reporting. The new setup in AutoJSAPI::ReportError checks for the current compartent being a window, which of course it is. |
||
|---|---|---|
| accessible | ||
| addon-sdk | ||
| b2g | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| db/sqlite3 | ||
| devtools | ||
| docshell | ||
| dom | ||
| editor | ||
| embedding | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| probes | ||
| python | ||
| rdf | ||
| release/docker | ||
| security | ||
| services | ||
| startupcache | ||
| storage | ||
| testing | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .eslintignore | ||
| .eslintrc | ||
| .gdbinit | ||
| .gitignore | ||
| .hgignore | ||
| .hgtags | ||
| .lldbinit | ||
| .ycm_extra_conf.py | ||
| AUTHORS | ||
| Android.mk | ||
| CLOBBER | ||
| GNUmakefile | ||
| LEGAL | ||
| LICENSE | ||
| Makefile.in | ||
| README.txt | ||
| aclocal.m4 | ||
| build.gradle | ||
| client.mk | ||
| client.py | ||
| configure.in | ||
| configure.py | ||
| gradle.properties | ||
| gradlew | ||
| mach | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| old-configure.in | ||
| settings.gradle | ||
| test.mozbuild | ||
README.txt
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure
For information on how to build Mozilla from the source code, see:
http://developer.mozilla.org/en/docs/Build_Documentation
To have your bug fix / feature added to Mozilla, you should create a patch and
submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at:
http://developer.mozilla.org/en/docs/Creating_a_patch
http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
If you have a question about developing Mozilla, and can't find the solution
on http://developer.mozilla.org, you can try asking your question in a
mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups
are accessible on Google Groups, or news.mozilla.org with a NNTP reader.]
You can download nightly development builds from the Mozilla FTP server.
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy. Firefox nightlies, for example, can be found at:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
http://nightly.mozilla.org/