According to the latest Firefox OS text selection spec 1.7, the carets
are now swappable.
MozReview-Commit-ID: 3V2f0woof77
--HG--
extra : rebase_source : 41e9c7691319bb9e7b2db67b98350cb5503f9519
We only update mImageWidth/Height when we get the load event for the img element. But the style sheet TopLevelImageDocument.css can be loaded after the img load event. TopLevelImageDocument.css specifies that the orientation of the image comes from the embedded exif data, thus when it is loaded the image can rotate and change size. So we need to be sure to re-get the size after all style sheets are loaded.
This means mImageWidth/Height could be wrong during loading.
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
|oOps| is short for "objectOps", which will contrast with the |cOps| "classOps"
field that the next patch will introduce.
--HG--
extra : rebase_source : 920662674e1f672d923cb9060de23c85dfc903bf
The configure.in is a small wrapper around python configure, that is
still a m4 script so that people running autoconf manually can still
do so without breaking their stuff (and we have jobs that do that
on automation as well).
But considering how simple the m4 is, to avoid having the autoconf
checking code twice (once in client.mk and once in
build/moz.configure/old.configure), we can just process it with sed
instead of autoconf.
Whether it uses locale._parse_localename or nl_langinfo makes it have completely
different results in weird and/or widespread locale settings (LC_ALL=UTF-8 or
LC_ALL=C).
Ideally, we'd use the tarballs from
http://llvm.org/releases/download.html but I didn't feel like modifying
the script more than I already did to make it work at all (bug 1262735).
The new tarball for Linux was built on
https://tools.taskcluster.net/task-inspector/#LCUn8aEgTBeRJ11a3qTlDQ/0
The new tarball for Mac was built on a loaner, after installing cmake
and ninja, as well as building ld64 127.2 from source because the
installed version would assert while building clang. The latter required
manually adding some missing headers to /usr/include. TSAN was also
disabled because it requires APIs that are not available on the OSX
version on the build slaves (e.g. pthread_introspection_hook_install).
Building clang also required using a mac clang from tooltool, the system
one lacking support for atomics.
The check is for the clang plugin, which is a host library. It is especially
important to use the host compiler for this check on OSX-on-Linux cross builds.
Both point to the same path for cc and cxx, but not for gcc_dir, which
makes no sense. That's the only significant difference between both, so
just merge them both, and use the merged file in the taskcluster build
script.
Instead, copy libgcc from the GCC used to build clang at each stage.
When passing --gcc-toolchain, the flag ends up appearing in the output
of llvm-config, and completely defeats the purpose of copying libgcc in
clang/lib/gcc.
Since build-clang.py requires a gcc_dir to be set, and we're using GCC
from there to build clang, we might as well copy libgcc from there
instead of building a fresh GCC. On the taskcluster job building clang,
GCC comes from a tooltool package that is already the result of
build-gcc anyways.
When passing -DCMAKE_C_COMPILER="gcc -flags" to CMake, ninja then tries
to literally call "gcc -flags", not "gcc" "-flags", and a "gcc -flags"
file obviously doesn't exist, so the build fails.
This fixes a regression from bug 1042132. Hopefully, this also doesn't
regress bug 1042132 itself.
Jan de Mooij
Carsten "Tomcat" Book
Sotaro Ikeda
Ting-Yu Lin
Timothy Nikkel
CJKu
Chris Peterson
Valentin Gosu
Mike Hommey
Peter Chang
Nicholas Nethercote
Nicholas Hurley
Tooru Fujisawa
Kyle Huey
Wes Kocher
James Graham
Kyle Machulis
Shu-yu Guo