These numbers are only used to calculate a percentage, so they don't really
need to be 64-bit long.
MozReview-Commit-ID: FfdyStjGITL
--HG--
extra : rebase_source : 704d7664a3462f68f2c495e3b5d66f71180d290b
VideoPlaybackQuality was fed uint64_t's, now it should be given uint32_t's.
Note that FrameStatistics currently provide uint32_t's, so we are fine now;
nevertheless I added a static_assert to verify that and ensure it stays true.
MozReview-Commit-ID: I0dgP1K4lg3
--HG--
extra : rebase_source : f8d673db0cd45d2b3ae03c092dff217e5d7ebbee
Because VideoPlaybackQuality attributes are exposed as 'unsigned long' (aka
uint32_t) in the webidl interface, it would be dangerous to accept and store
them as uint64_t in the class.
MozReview-Commit-ID: EhX4lhTbA3c
--HG--
extra : rebase_source : ed1e745c7d69babe6875677e3c8a16a9d6f3172c
The asserts are:
###!!! ASSERTION: Bounds computation mismatch: 'mContainerBounds.IsEqualInterior(mAccumulatedChildBounds)', /layout/base/FrameLayerBuilder.cpp, line 4887
###!!! ASSERTION: bad aListVisibleBounds: 'r.GetBounds().IsEqualInterior(aListVisibleBounds)', /layout/base/nsDisplayList.cpp, line 1637
They happen because we have a wrap list item that contains an out of flow frame with no saved clip data. So the patch for this bug changes the scroll clip of the wrap list item from the scroll clip induced by the root scroll frame to the null scroll clip. All of the display items that the wrap list contains have the root scroll frame scroll clip, so this causes the scroll clipped bounds for the wrap list item to expand to the whole content area. These expanded bounds of the wrap list item get incorporated into the bounds of a parent transform item. Later the wrap list item is flattened away, and so it's no longer around to provide the expanded bounds, leading to the assertions.
I've thought through options like changing how scroll clipped bounds work for wrap list items, but I can't seem to find any solution that would be consistent. The best thing would be to get the proper clip on out of flows we are going to descend into, but I can't think of a good way to do that either in this case (or in general).
Since bug 1253512 landed, it's possible for DeadBlocks to lack an allocation
stack.
--HG--
extra : rebase_source : 0efc60192ed0992d2f68838d95586cd888765586
The main change is that once we discover we have a bad-url-token we consume
everything up to, but not including, the next ')' character. While we do this
we can cross line boundaries and don't bother about matching braces or quotes.
We just keep going until we find the ')' or hit EOF.
In nsIFrame::BuildDisplayListForChild for certain types of frames we create wrap list items to wrap the constructed display list to make those items inseperable.
We were using the current scroll clip by default when creating these items, but that scroll clip may not contain all the content in the display list if we traversed into an out of flow frame whose containing block is an ancestor of the current frame. The CurrentAncestorScrollClipForStackingContextContents keeps track of exactly this. (Its name might be a little misleading as we may not be dealing with a true stacking context here. Nevertheless it does contain the correct clip.)
We also need to initialize the value of mStackingContextAncestorSC when we create an AutoSaveRestore because we are now using that value sometimes without calling Enter/ExitStackingContext (which initializes mStackingContextAncestorSC).
Since bug 822869 the referrer trimming has relied on using prePath when
trimming resulting in non-ASCII hosts being passed through in UTF-8 (or
whatever their encoding was.)
Prior to this patch, the logic when trimming was to generate the referrer
string using prePath and possibly nsIURL.filePath, then re-derive the
nsIURI from that string.
Concerned about the cost of introducing asciiPrePath just for this consumer,
I opted to have the code just combine the scheme and asciiHostPort to
approximate the prior use of prePath. (userPass is explicitly cleared by
the code.)
Concerned about weirdness/loss of fidelity in the nsIURI, I replaced the
code that re-derived the URI from the spec string with manual clearing
of the parts of the URI/URL we were not including. This may not be the
right thing to do.
I modified the existing Gecko-specific test coverage of SetReferrerPolicy.
The existing web platform tests and referrer policy didn't seem concerned
with this case, and the bug is indeed localized to a very small segment
of Gecko code. Note that the userReferrerTrimmingPolicy=1 bug case can
only be triggered by explicit user preference setting and this is only
tested in test_referrer.js. userReferrerTrimmingPolicy=2 need not be
set by preference if REFERRER_POLICY_ORIGIN or
REFERRER_POLICY_ORIGIN_WHEN_XORIGIN (when cross origin) is used.
Gerald Squelart
Carsten "Tomcat" Book
Iris Hsiao
JW Wang
cku
Timothy Nikkel
Nicholas Nethercote
Alexandre Poirot
Boris Zbarsky
Randell Jesup
Wes Kocher
Michael Layzell
Luke Wagner
Nils Ohlmeier [:drno]
Kartikaya Gupta
Jeff Gilbert
David Anderson
Corey Ford
Mike Taylor
George Wright
Andrew Sutherland