========
https://hg.mozilla.org/integration/gaia-central/rev/eeb5c1c0cf24
Author: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Desc: Merge pull request #27294 from azasypkin/bug-1116736-browser-net-error-dialog
Bug 1116736 - [Flame][Browser]The "Try again" button is covered and device only shows a little bit blue icon in the lower right corner. r=bfrancis, johnhu
========
https://hg.mozilla.org/integration/gaia-central/rev/254378bebef6
Author: Aleh Zasypkin <azasypkin@mozilla.com>
Desc: Bug 1116736 - [Flame][Browser]The "Try again" button is covered and device only shows a little bit blue icon in the lower right corner. r=bfrancis, johnhu
========
https://hg.mozilla.org/integration/gaia-central/rev/0fabeb1cb7a6
Author: Chris Lord <chrislord.net@gmail.com>
Desc: Merge pull request #27248 from Cwiiis/bug1112596-loadstart-before-chrome-load
Bug 1112596 - Fix loading indicator not showing on load. r=alive
========
https://hg.mozilla.org/integration/gaia-central/rev/f0fa802cd420
Author: Chris Lord <chrislord.net@gmail.com>
Desc: Bug 1112596 - Fix loading indicator not showing on load. r=alive
If a page triggers a loadstart before the app chrome loads, the app chrome
will not show the loading state.
The change to GetAfterFrameForContent prevents the reframe that is part
of the chain of events leading to this bug, and thus fixes the bug on
its own. The change to GetBeforeFrameForContent seems desirable for
symmetry.
Note that patch 6 also independently fixes the reported bug.
This probably needs somewhat careful review. We should examine:
(1) what the rules for calling nsLayoutUtils::GetBeforeFrame and
nsLayoutUtils::GetAfterFrame are, and whether both (or neither)
need to be patched.
(2) What the rules are for which frame the GenConProperty() lives on,
and whether we should adjust nsIFrame::GetGenConPseudos() to either
do something more intelligent, or assert about callers.
(We should probably clean up some of these things in a followup bug.)
Since the symptom of this bug is (once patch 4 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
This patch fixes the assertion on layout/generic/crashtests/600100.xhtml,
though I haven't investigated why.
This patch is not needed to fix the bug, but it seems like it's probably
desirable. It's not needed for this bug because
MaybeReframeForBeforePseudo and MaybeReframeForAfterPseudo are already
called (by ElementRestyler::RestyleChildren) on only the first and last
continuation or ib-split sibling with the same style. So this patch
should only actually change anything for cases like a block-in-inline
split whose initial inline part is inside of a ::first-line (where
different parts of the block-in-inline split chain have different style).
Since the symptom of this bug is (once patch 6 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
This counts are intended to be useful for:
* tests
* perhaps developer tools
that need to determine whether frame construction or reflow has happened
in a particular interval.
In Fennec, if the root window gets resized, background tabs get a delayed
resize event queued up. When those background tabs get painted next, the delayed
resize is flushed. However, the code that flushes the delayed resize does not
check to see if the viewport is already overridden. This is in contrast to all
the other code paths that propagate outerwindow size change to the innerwindow,
and is incorrect because it effectively clobbers any meta-viewport tag with the
outerwindow dimensions. This patch corrects this code path to also check if the
viewport is overridden.