Previously, the build system may silently missing test files defined in
manifests. This patch makes missing test files a fatal error, detected
when reading test manifests.
The test_bug872273.html XBL test appeared to be orphaned in
content/xbl/test. It has been reunited with its family.
dom/tests/mochitest/notification referenced a single test file which was
recently deleted. That manifest has been removed.
Missing test files related to the Python unit tests for the build system
have been added. (They are a bunch of empty files.)
--HG--
extra : amend_source : cb6b9bf91e57569c8be312d3c16fef69b2b0b950
Previously, the build system may silently missing test files defined in
manifests. This patch makes missing test files a fatal error, detected
when reading test manifests.
The test_bug872273.html XBL test appeared to be orphaned in
content/xbl/test. It has been reunited with its family.
dom/tests/mochitest/notification referenced a single test file which was
recently deleted. That manifest has been removed.
Missing test files related to the Python unit tests for the build system
have been added. (They are a bunch of empty files.)
--HG--
extra : rebase_source : 8c64986169064401951585c07deadada8c905550
This builds a new Java JAR containing only org.mozilla.gecko.R. This
new JAR file is included in Fennec, but not included in
geckoview_library. (Usually ant, gradle, or Eclipse arranges to produce
org.mozilla.gecko.R but not include it in the classes.jar output as part
of a library project. This mimics that.)
Changing the GeckoView package to org.mozilla.gecko declares to
consuming applications that they should produce org.mozilla.gecko.R,
replacing what was removed above (but with correct resource IDs).
It's good practice to have default values for all preferences in all.js.
Otherwise some preference APIs throw exceptions and/or leave values
uninitialized. It also makes the preference show up in about:config.
Bug 875204 accidentally removed this line from all.js even though the
pref was not removed. (The pref was initially added in bug 780342.)
I've been wanting to remove this code for a while. I think this code is
problematic for three reasons:
(1) It's in the middle of code where it doesn't belong, and which ought
to be handling purely-style-system things. (This is blocking me
from reusing that code elsewhere, e.g., in bug 977991 and
bug 960465, both of which could use it in some form.)
(2) It defeats the optimization from bug 790505 whenever we do a
miniflush (in other words, whenever we have any style change,
whether or not it's related)
(3) It means the conditions for when we decide to ship a new set of
animation data to a layer doesn't cover all the cases the layer
needs it. In particular, we only run this miniflush code when we
have a currently running animation or transition that's running on
the compositor thread. On the other hand, the UpdateTransformLayer
style change handling in DoApplyRenderingChangeToTree depends on
whether the frame currently has a transform layer, which can
continue to be true for a bit after the animation stops. So if we
need to send animations to the layer because of a transform style
change that happens soon after an animation completes, our style
change handling will find the existing layer and call its
SetBaseTransformForNextTransaction method but never do anything
that triggers layer construction. The style throttling code, in
turn, will never stop doing main thread updates because the
animation generation on the layer is out-of-date, and these main
thread updates will keep the layer active, but they'll never show
up because the stale animation data overrides the new transform
that we've been setting. (At least, I think that's what was
happening; it makes sense to me and matches the behavior I was
observing. I didn't verify which main thread updates and which
layer updates were actually happening, though.)
This shows up, for example, in the animation in attachment 8384813
just halting at a corner if I'm careful not to disturb it. (I'm
testing on Linux, with both accelerated layers and OMT animations
explicitly enabled.)
I think there are probably some other things that can be removed as
followups to removing this code, because I think we made some boundary
conditions intentionally incorrect so that problem (3) above wouldn't be
as bad as it otherwise would have been.
The first provides a reasonable default (failure to parse) for the case
of an unknown value type (which should never happen).
The second reorders two failure checks so that the one that returns
early when units is uninitialized happens before the one that looks at
units.
I think this could have been done as part of Bug 700981 part 2, which
moved AddToIdTable and RemoveFromIdTable calls from nsStyledElement to
nsGenericElement.
This fixes an out-of-memory foreground-tab crash that I could reliably
reproduce on a 256MB Firefox OS phone, and I think also significantly
reduces the number of background tabs I'm seeing killed due to low
memory.
