This is more likely to be correct, and a necessary step in case we ever want
to move to Object.is.
This keeps ise as an alias for is, and introduces is_loosely for the old
behaviour.
Given alignment requirements on most platforms, there will be at least 3
bytes of padding after mRequestRegistered in its current location, and
at least one unused byte at the end of the structure. We can move
mRequestRegistered after mLoadFlags so that it packs properly with the
boolean flags already there for less wasted space.
nsSprocketLayout::Layout lays out its children by looping from first child to last child updating local variables x, y as it goes that keep track of the position where to layout the current child.
If the box is horizontal it works left-to-right or right-to-left according to wheather the direction of the box is normal or not. Vertical boxes work similarly top-to-bottom or bottom-to-top. Vertical boxes also respond to CSS direction styles, so that in an LTR box the child boxes are laid out flush left, but flush right in an RTL box. Herein lies the bug, some code assumes the child boxes are laid out flush right in RTL, but the code to actually position the children positions them flush left.
The code that assumes the child are laid out flush right is HandleBoxPack, which determines the origin to start laying out children at, and the code which uses HandleBoxPack to determine if the origin changed during the laying out of the children, and then shifts the children by the amount the origin shifted. The size of our box changing will, in general, change the position of the origin. So the children aren't laid out to the origin that HandleBoxPack expects they will get moved to wrong positions.
nsSprocketLayout::Layout lays out its children by looping from first child to last child updating local variables x, y as it goes that keep track of the position where to layout the current child.
If the box is horizontal it works left-to-right or right-to-left according to wheather the direction of the box is normal or not. Vertical boxes work similarly top-to-bottom or bottom-to-top. Vertical boxes also respond to CSS direction styles, so that in an LTR box the child boxes are laid out flush left, but flush right in an RTL box. Herein lies the bug, some code assumes the child boxes are laid out flush right in RTL, but the code to actually position the children positions them flush left.
The code that assumes the child are laid out flush right is HandleBoxPack, which determines the origin to start laying out children at, and the code which uses HandleBoxPack to determine if the origin changed during the laying out of the children, and then shifts the children by the amount the origin shifted. The size of our box changing will, in general, change the position of the origin. So the children aren't laid out to the origin that HandleBoxPack expects they will get moved to wrong positions.
We don't need to use manual NS_{ADDREF,RELEASE} here when nsRefPtr will
do that for us. The manual QueryInterface invocation only serves to do
an expensive static_cast and increase the refcount; we can forget our
reference into mListener to achieve the same effect.
