зеркало из 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
f67ab8c057
Currently we only permit requests from HTTP channels to be retargeted to the image IO thread. It was implemented this way originally in bug 867755 but it does not appear there was a specific reason for that. The only kink in this is some browser chrome mochitests listen on debug build only events to ensure certain chrome images are loaded and/or drawn. As such, this patch ensures that those observer notifications continue to be served, requiring a dispatch from the image IO thread to the main thread. Another issue to note is that SVGs must be processed on the main thread; the underlying SVG document can only be accessed from it. We enforce this by checking the content type. The possibility already exists that an HTTP response could contain the wrong content type, and in that case, we fail to decode the image, as there is no content sniffing support for SVG. Thus there should be no additional risk taken by using the image IO thread from other non-HTTP channels (if they don't specify the SVG content type, it is not rendered today, and if they do, it will remain on the main thread as it is today). We also ignore data URIs. The specification requires that we process these images sychronously. See bug 1325080 for details. |
||
---|---|---|
.cargo | ||
.vscode | ||
accessible | ||
browser | ||
build | ||
caps | ||
chrome | ||
config | ||
db | ||
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 | ||
security | ||
services | ||
servo | ||
startupcache | ||
storage | ||
taskcluster | ||
testing | ||
third_party | ||
toolkit | ||
tools | ||
uriloader | ||
view | ||
widget | ||
xpcom | ||
xpfe | ||
.clang-format | ||
.clang-format-ignore | ||
.clang-tidy | ||
.cron.yml | ||
.eslintignore | ||
.eslintrc.js | ||
.flake8 | ||
.gdbinit | ||
.gdbinit_python | ||
.gitignore | ||
.hgignore | ||
.hgtags | ||
.inferconfig | ||
.lldbinit | ||
.taskcluster.yml | ||
.yamllint | ||
.ycm_extra_conf.py | ||
AUTHORS | ||
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 | ||
npm-shrinkwrap.json | ||
old-configure.in | ||
package.json | ||
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: https://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: https://developer.mozilla.org/en/docs/Creating_a_patch https://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 https://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 - https://nightly.mozilla.org/