The run ID for a plugin is retrieved and cached in the nsObjectLoadingContent
on plugin instantiation.
--HG--
extra : rebase_source : d1e87b7751e6367c482b2420aa43bfadbce5e3e8
Normally, this could be served by the process ID of a plugin, however, run ID is meant
to be consumed by multi-process browser chrome code for telling different runs of a
plugin apart (for example, for searching the DOM for a crashed instance of a plugin,
while ensuring that we don't accidentally find newly spawned instances that have not
crashed). Exposing something as low-level as the process ID to browser chrome code
seemed like Too Much Information. Also, there is the extremely unlikely chance that
a process ID might be re-used immediately after the original process shuts down. This
run ID avoids that case, regardless of how unlikely.
--HG--
extra : rebase_source : 4f0072ef660645efdb26d8fa7c9f03dfc60a4f4a
This is needed so that we can throw a TypeError from
FetchPut::FetchComplete. In order to be able to do this, we need to
store the entire ErrorResult in the FetchPut object and deliver it to
the other side.
This object is not copyable, so it should probably not be
assignable either, especially since the compiler generated
copy constructor can potentially cause UAF issues on the
mMessage member, for example.
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.
If chroma_format_idc isn't defined, chroma_format_idc shall be inferred to be
equal to 1 (4:2:0 chroma format).
Also, ignore nonsensical cropping values as per spec.
