mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Gecko engine for Wine
3e118befc1
Installing a Webapp is an asynchronous job, and there is a pocket of time between when web content requests to install an app and before the browser displays an installation prompt that the outer window of the content can browse away. This pocket of time is typically used by XHR to request the web app resources and verify their contents. This pocket of time is, essentially, bug 771294, and is a bit of a security problem. This problem was originally patched over on Desktop by checking in the parent process that the outer window was still at the same URI as it had been when it made the request. I'm not entirely sure if Android / B2G made similar checks. With separated content processes, however, the browser front-end can no longer performantly check to ensure that the outer window is at the same URI. We solve this problem by sending up a message in the content process when the location of an outer window making use of navigator.mozApps changes. We hold a Map of "actions" mapping to in-flight installs mapped by the outer window ID of the requesting content. When we notice a location change, we mark those actions as cancelled. When the XHR returns, we have it check the state of its actions, and if they're cancelled, it aborts further action. Normally, this wouldn't be necessary, since any XHR initiated by the content window would be cancelled once the location changed, but in this case, the XHR is occurring in Webapps.jsm, and is not influenced by the outer window of the content. |
||
---|---|---|
accessible | ||
addon-sdk | ||
b2g | ||
browser | ||
build | ||
caps | ||
chrome | ||
config | ||
content | ||
db/sqlite3 | ||
docshell | ||
dom | ||
editor | ||
embedding | ||
extensions | ||
gfx | ||
hal | ||
image | ||
intl | ||
ipc | ||
js | ||
layout | ||
media | ||
memory | ||
mfbt | ||
mobile | ||
modules | ||
mozglue | ||
netwerk | ||
nsprpub | ||
other-licenses | ||
parser | ||
probes | ||
profile | ||
python | ||
rdf | ||
security | ||
services | ||
startupcache | ||
storage | ||
testing | ||
toolkit | ||
tools | ||
uriloader | ||
view | ||
webapprt | ||
widget | ||
xpcom | ||
xpfe | ||
xulrunner | ||
.clang-format | ||
.clang-format-ignore | ||
.gdbinit | ||
.gitignore | ||
.hgignore | ||
.hgtags | ||
.lldbinit | ||
aclocal.m4 | ||
Android.mk | ||
AUTHORS | ||
client.mk | ||
client.py | ||
CLOBBER | ||
configure.in | ||
GNUmakefile | ||
LEGAL | ||
LICENSE | ||
mach | ||
Makefile.in | ||
moz.build | ||
mozilla-config.h.in | ||
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: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/ - or - http://nightly.mozilla.org/