While resolving style context, the primary frame of the target element
has previous style context so if we don't pass the newly created nsStyleContext,
UpdateCascadeResults uses the previous style to get overridden properties, it
will result unexpected cascading results.
MozReview-Commit-ID: osqXQlP43X
--HG--
extra : rebase_source : 1b34f9245367c2613807156559f09f5f2943458c
To create a stacking context for animations on transform:none segment,
we need to set NS_FRAME_MAY_BE_TRANSFORMED. The fix is comming in part 2.
Note that in case of animations which has properties preventing running on
the compositor, e.g., width or height, corresponding layer is not created
at all, but even in such cases, we normally set valid change hint for such
animations in each tick, i.e. restyles in each tick. For example:
div.animate([{ opacity: 1, width: '100px' }, { opacity: 0, width: '200px' }], 1000);
This animation causes restyles in every ticks without this patch, this patch
does not affect such animations at all. The only animations which will be
affected by this patch are animations which has opacity/transform but
did not have those properies. e.g, setting transform by setKeyframes or
changing target element from other target which prevents running on the
compositor, etc.
MozReview-Commit-ID: 78fYqyX8uDX
--HG--
extra : rebase_source : c4a6ef244f26f3d808fd2c6a5f80c1a15478ae31
If the frame already has the NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO bit we are going to descend into it anyways, so we may as well store the oof data so we can have the correct clip.
Sometimes we add the bit after this test though, so it doesn't allow us to have the proper clip in all cases.
The mobile session store saves the current document resolution in order to restore the previous zoom level when restoring a page. If the display width has changed since the session data was captured (e.g. because the device was rotated), the resolution might have to be scaled appropriately.
Currently, the session store does this scaling by itself by comparing the stored and current window widths, however this implementation is slightly simplified and doesn't cover all use cases, which means some pages can be restored at a wrong zoom level after rotation. To correctly cover all cases, the session store would have to compare viewport widths, too.
Because the MobileViewportManager doesn't wait for the session store to set the restore resolution, the latter has to call setRestoreResolution() as early as possible in order to guarantee that the restore resolution is set before the first paint of the document. Therefore the session store currently calls this after receiving a LocationChange notification. However at that time, the correct viewport for the current document is not yet available, which means the resolution cannot be recalculated by the session store at that point.
Therefore, this patch changes the approach taken and lets the MVM handle all resolution calculations instead. The session store now simply passes the stored previous display dimensions along with the previous document resolution to the MVM, which can then compare them to the current display and viewport widths and scale the resolution appropriately before using it during first paint.
MozReview-Commit-ID: IGxWw87yftK
--HG--
extra : transplant_source : e%8D%BD%26%D2%C3%8E5%E3%2B%C0t%BA%DB%C1%BBs%3F%13%1F
We'll want to use this during first-paint, too, in order to correctly scale the resolution as received by the session store if we're restoring a previous tab. Therefore we extract this code into a separate helper function.
MozReview-Commit-ID: KCdvmyrP4mJ
--HG--
extra : transplant_source : c%BD%99%9D%F8%9EW%D2%8B%BD%E0a%82%ED%3B%EE%EF%ACl%D6
Use ReconstructFrame to replace NS_STYLE_HINT_FRAMECHANGE in many places, such
as HTML*Element::GetAttributeChangeHint and HTMLFrameSetElement::SetAttr.
MozReview-Commit-ID: EHbc4RMeuu0
--HG--
extra : rebase_source : f5163608c88362595ef5af5fcd36fa64c9c79ce7
Use ReconstructFrame | (any ther bits needed) to replace
NS_STYLE_HINT_FRAMECHANGE in nsStyle*::MaxDifference.
For those nsStyle* that do not have nsChangeHint_NeutralChange in their
CalcDifference, we should be able to elimate nsChangeHint_NeutralChange from
their MaxDifference as well.
MozReview-Commit-ID: B3VJWt6gKoL
--HG--
extra : rebase_source : 7b568b680be4ea108b08cc565f1651ded70d357d
Replace NS_STYLE_HINT_FRAMECHANGE with nsChangeHint_ReconstructFrame in
nsStyle*::CalcDifference.
MozReview-Commit-ID: 85WPCyYolal
--HG--
extra : rebase_source : 3a5e247fe38e0b75d9ea1826ce5758b5a5862675
The comment for nsChangeHint_ReconstructFrame is out-of-date.
In RestyleManager::ProcessRestyledFrames, we actually ignore all of the other
hints if ReconstructFrame is set. The old version was written when
ReconstructFrame was listed last. So, update the comment.
MozReview-Commit-ID: 97wMrW6S6ID
--HG--
extra : rebase_source : f1556012073e088af96c2e389532f1ae04b165af
According to our coding style guide, we should always brace controlled
statements, even a single-line consequent of an if-else-statement. It avoids
dangling else bugs.
MozReview-Commit-ID: FT1AR5MqOGw
--HG--
extra : rebase_source : 111b4f70c83a59ee7dab8bf8adf60bc10916cc79
The content clip is still valid, as we are only descending into content descendants.
The clip for content descendants that the root scroll frame creates so content doesn't overflow (visually or for event handling) the main scrollbar can get cleared otherwise.
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : histedit_source : 5390eeebfe9a2791d9ac8e91ec1dfec4ec7b4118
Remove unnecessary nsChangeHints used in
nsStyle*:DifferenceAlwaysHandledForDescendants. Accordingly,
nsStyle*:MaxDifference can be simplified as well.
This is a followup patch for part3.2 in Bug 906116.
MozReview-Commit-ID: GgU9xgghCO7
