While debugging bug 858937 I noticed that the transition manager was
calling nsIFrame::SetStyleContextWithoutNotification rather than
nsIFrame::SetStyleContext. SetStyleContextWithoutNotification should
only be used for things that aren't really style changes, but are
instead changes we make during frame construction before things are
really initialized. Anything that's really a dynamic style change, as
these are, should use SetStyleContext.
I realize I said the opposite in bug 780692 comment 186, and bz said the
same in bug 780692 comment 204, which is why this is the state that it
is.
A new build tier is introduced: precompile. The intention is to replace
the export subtier with something better and nonrecursive. IPDL and
WebIDL code generation have been moved into this new tier and are
performed concurrently. This appears to reduce build times due to fewer
"single threaded" build actions.
The subtier tracking UI has been updated to reflect operations that can
occur in parallel. As subtiers are started, they turn yellow. They can
then complete in any order.
Nonrecursive targets have been added to preserve the IPDL and WebIDL
build targets such that developers can type |make| from leaf directories
like they have always done.
This change reworks how TabContext stores its data. Before, it stored
an app-id and translated that into an app; now we do the reverse. This
lets us guarantee that HasOwnApp() is true iff GetOwnApp() is non-null.
We added a new class, MaybeInvalidTabContext to assist with converting
from an IPCTabContext to a TabContext. This allows us to ensure that a
TabContext object is never invalid.
========
https://hg.mozilla.org/integration/gaia-central/rev/775b20c42b52
Author: Julien Wajsberg <felash@gmail.com>
Desc: Bug 890443 - [SMS] the "fixed header" style and transitions should be adjusted so that it's not jumping when changing header r=schung
Important changes
* changes how the fixed header is found. Now we're iterating starting with the
top instead of the bottom. In the SMS app, the most common cases is when the
list is not scrolled so much, and therefore starting at the top will likely be
way faster once the list is long.
* we don't position the header in the same loop, now we position the header
depending on the next header, if it exists.
* we use a specific hiding class instead of specifying the 100% transform
translation in the js code. Also, using a 100% transform translation is used
instead of display none, so that we can get some necessary measurements in the
init method. Most notably, we need to take into account the view's padding
top.
Less important changes:
* changed the desktop mock so that we have more headers when loading in Firefox
* check that we have mozSetMessageHandler before using it so that we can launch
the app in main Firefox
* moved the first header's margin top to the view's padding top. This makes it
easier to calculate the exact location to trigger the fixed header switch
effect.
