GPS handling for Gonk abuses the Settings API in two ways. First, on
mozsettings-changed event, it will trigger two new requests to read
values (debug enabled and GPS locations ignore). This is useless since
the event already contains the key that has changed and the new value,
so there is no need to do a createLock().get() call. Then, in startup
code, the Init() method is supposed to check itself whether it is
already running. This is done through the mStarted boolean. The same
Init() method is responsible for adding the mozsettings-changed
observer, which is removed by the Shutdown() method. Investigation on
device by using the Geolocation API has proven that we were leaking some
observers. This is because checking mStarted boolean is performed after
we request settings values and we install the mozsettings-changed
observer. So any time the Init() gets called, we install it but we just
remove it once in Shutdown().
- scroll-behavior-8.html - Tests if dynamically changing the scroll-behavior
css property on a div element takes effect after the page has been painted and
reflowed.
- scroll-behavior-9.html - Tests if dynamically changing the scroll-behavior
on the body element takes effect after the page has been painted and
reflowed.
- When the scroll-behavior CSS value changed, the nsChangeHint_NeutralChange
hint was returned by nsStyleDisplay::CalcDifference. It now returns
nsChangeHint_ReconstructFrame to ensure that the change takes effect.
- When scroll-behavior is changed, the nsChangeHint_NeutralChange was not
sufficient to enter nsCSSFrameConstructor::PropagateScrollToViewport. By
using the same hint as used when the overflow css property changes,
nsChangeHint_ReconstructFrame, PropagateScrollToViewport will be called.
- The scroll-behavior css property is not expected to change often (the
CSSOM-View DOM methods are likely to be used in those cases); however, if
this does become common perhaps a faster-path might be worth while.
We modify the environment before running freetype2 configure. When it uses
the same cache file, it stores knowledge about that environment in the cache
file. The cache file is then reused to configure in js/src, with yet again a
different environment, which makes subconfigure.py clear the cache because
of the differences.
The configure in js/src is however invoked with the same environment as the
main configure was invoked with (mostly), so without freetype2 on the way,
reusing the cache for it works as expected. In fact, it works better with the
cache because of things coming from mozconfig that are not exported.
With freetype2 on the way, as mentioned above, the cache is cleared. Without
the cache, js/src/configure does new detections with a possibly different
environment, and stores that in the cache. Until the next build, which then
uses that different cache for the top-level configure.
This results in subtle differences in the HOST_CC/HOST_CXX variables on
android builds because those variables are not exported from mozconfig,
depending on PATH, what the builder was building before, and if the build
is a clobber.
Avoiding the freetype2 subconfigure writing its environment variables change
to the top-level cache makes the cache never invalidate for js/src.
$topsrcdir/gcc/bin was mistakenly added in bug 971841, but is not provided by
anything the tooltool manifest for android builds pulls. It however is a path
that /may/ exist in the source tree when the slave ran a linux build before.
When it does exist, the meaning of non-path-prefixed commands change,
influencing what particular compiler is used in some cases.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This hack has actually not been actively used since sqlite, nss and nspr are
all folded together, because no shared library is actually linked in
db/sqlite3/src.
Most of the TCPSocket and TCPServerSocket coverage was implemented exclusively
in Chrome-privileged xpcshell tests. This failed to provide coverage for the
key use case of content-privileged code using TCPSocket.
This cleans up the test implementation and migrates them to mochitests.
Coverage is improved as evidenced by two tested TCPServerSocket issues that were
addressed in this patch:
- ArrayBuffers weren't being created in the content page's context, so
exceptions would be thrown when accessed.
- 'drain' notifications were not being hooked up.
The following fix that lacks coverage that notices the fix was implemented:
- TCPServerSocket now properly propagates the appId for network usage tracking.
The %#x format specifier for hex values doesn't work with our
logging macros, and MacOS error codes are generally listed
in decimal anyway.
Also log the reason for a Drain() call to assist debugging.
