We're now asserting that we never check these before the END_ALL_PREFS phase,
which means they don't need to be sent to the content process synchronously.
MozReview-Commit-ID: 4BGbvVCjDWz
This ensures that we don't read incorrect values out of the gPropertyEnabled
array simply because we haven't gotten preference values from the parent process
yet.
MozReview-Commit-ID: 59AgN3ecXQl
This will make the timing of the change more consistent between SetAttr and
UnsetAttr, and ensure that we have both the old and new type available in
AfterSetAttr.
MozReview-Commit-ID: Gsrxkkve7BC
The UpdateState calls in BeforeSetAttr were there in case an AttributeWillChange
observer examined the element state and expected it to be updated to whatever
changes BeforeSetAttr made. But at this point, AttributeWillChange runs before
BeforeSetAttr, and there is no code that runs between BeforeSetAttr and the
subsequent UpdateState in SetAttrAndNotify/UnsetAttr that cares or could care
about the state of the element. So it's safe to do no state updates in
BeforeSetAttr and just do the single UpdateState we already do.
MozReview-Commit-ID: BQOPVgHyC0H
This means that implementations of BeforeSetAttr no longer need to UpdateState.
Those UpdateState calls will be removed in a bit.
MozReview-Commit-ID: 1yEg5D4garD
This removes the requirement that BeforeSetAttr comes before AttributeWillChange
(which needs the preparsed new value).
MozReview-Commit-ID: 87C6Mjc7ARh
The PR in question just added some pseudo-classes, and seems to have unearthed
some failures related to our lack of proper visited handling. Annotating.
MozReview-Commit-ID: GcbmWNDgwD0
sutagent is no longer built or usedr; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and the --dmTrans and similar options have been removed
from test harnesses and mach commands.
I found this problem because I was debugging the failure of
layout/reftests/w3c-css/received/css-writing-modes-3/clearance-calculations-vrl-008.xht
with my patch for bug 1308876. It was failing because the red reference
box that was intended to be covered up was being mispositioned leftwards
by the width of the scrollbar, since we were not reflowing it when we
decided that the viewport did not need scrollbars. This patch fixes
that failure.
This led me to this bug, where
nsAbsoluteContainingBlock::FrameDependsOnContainer was incorrectly
testing conditions for when the values of 'top', 'right', 'bottom', and
'left' require reflow due to changes in the size of the containing
block.
The old code is incorrect in a number of cases, such as:
1. in RTL, with 'right: 100px', it will say that the frame does not
depend on its container's width since 'right' (offset-inline-start)
is a fixed offset and 'left' is 'auto'. However, since the
positioning is relative to the right edge, a change in container size
does require that the absolutely positioned element be repositioned
relative to the container's left edge.
2. In vertical-rl, again with 'right: 100px', it will make the same
mistake, since 'right' (now offset-block-start) is a fixed offset.
This is the case from the test I was debugging.
3. In vertical-rl with rtl direction and 'bottom: 100px', we will make
the same mistake because 'bottom' (inline-start) is fixed and 'top'
is 'auto', and we use 'bottom' rather than 'top'.
However, in cases (1) and (3) we actually avoid hitting the bug in these
simple-ish cases because ReflowInput::ShouldReflowAllKids() returns true
whenever IsIResize() is true, which means that
nsAbsoluteContainingBlock::Reflow doesn't even call
FrameDependsOnContainer. However, FrameDependsOnContainer should still
do the right thing because it's needed for
nsAbsoluteContainingBlock::MarkSizeDependentFramesDirty, which is only
used (from nsBlockFrame) when we reflow again for clearance or for
interruptible reflow. I haven't attempted to write a testcase for that
because it seems likely to require spending hours in the debugger trying
to trigger the right code.
This means that the only test that fails prior to the patch is
dynamic-offset-vrl-001.html, which exercises case (2), and also happens
to be the most similar to problem in clearance-calculations-vrl-008.xht.
This patch also makes the tests stricter so that we do optimize away
resizes in some cases where we're able to do so, such as
'left: 100px; right: auto' in RTL. (Or, rather, we would if it weren't
for the IsIResize() in ShouldReflowAllKids().)
MozReview-Commit-ID: 8xm1AHC21oh
--HG--
extra : transplant_source : %06%B4%40%EB%A9%C8M%F3%99%80%A9%DE%1F%1E%90%D3%F1%04W.
Use the global EventDispatcher for signaling update results. The event
listener in about.js must be unregistered after every event to prevent
memory leaks, so expectUpdateResult() is added and called whenever we
are expecting update results.
Kris Maglione
JerryShih
Yura Zenevich
Geoff Brown
vincentliu
Ben Kelly
Stanford Lockhart
Steve Fink
Jonathan Kew
Kartikaya Gupta
Boris Zbarsky
Wes Kocher
Dragana Damjanovic
Michael Layzell
Florian Quèze
Bobby Holley
L. David Baron
Jim Chen
Sebastian Hengst
Kai Engert
ffxbld