Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
The assert is testing that the content's primary frame shouldn't
generate any native anonymous children, but what we really want to
ensure is that :-moz-column-span-wrapper doesn't create any native
anonymous child (because we don't restyle the wrapper), not the content
which creates ::-moz-column-span-wrapper. The condition is already
guaranteed by !aFrame->HasAnyStateBits(NS_FRAME_OWNS_ANON_BOXES) above.
Also, at this point during the frame construction, we haven't associate
the content with the its primary frame. Therefore,
nsContentUtils::AppendNativeAnonymousChildren() won't return anything
except for scrollbars on root element. That's why we have the crash in
this bug.
Differential Revision: https://phabricator.services.mozilla.com/D12359
--HG--
extra : moz-landing-system : lando
The contain:paint clipping would be redundant and hence unnecessary in this
scenario, because:
- Scroll frames already clip their descendant frames.
- contain:paint has other (non-clipping-related) effects that prevent
descendant frames from escaping the scrollframe ancestor.
So, no further clipping is required.
This is a behavior change - it works around an issue that makes us fail to
repaint mousewheel-scrolled content inside of any scrollframe that returns true
from ShouldApplyOverflowClipping().
Differential Revision: https://phabricator.services.mozilla.com/D12056
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This test would fail with the upcoming bug 1159042 (dynamic reflow roots),
without the RecomputePosition fix in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D9481
--HG--
extra : moz-landing-system : lando
This is enough to fix the devtools regression and matches what other browsers
do in the no-attribute case.
Also, I think this change over all makes sense: it doesn't make any sense to
display the broken image icon if there's no request, and we already assume in
EnsureIntrinsicSizeAndRatio() that we don't paint the icon for those (and make
the intrinsic size 0x0).
We still show the border, which matches other UAs (note that devtools
effectively masks the border away with mask-image).
This technically also can change behavior of <object> and <input>, but I think
it's better to be consistent, since EnsureIntrinsicSizeAndRatio also doesn't
special-case <img> either.
Differential Revision: https://phabricator.services.mozilla.com/D11659
--HG--
extra : moz-landing-system : lando
Badly-behaved consumers of DrawTargetRecording can trigger recording of
draw calls that will fail to allocate required draw targets when the
recording is replayed. This patch tries to guard against this by
detecting these situations at record-time rather than crashing at
replay-time. When such a situation is detected, it will crash (for
content processes, to catch such scenarios) or gracefully fail (for
other processes).
Differential Revision: https://phabricator.services.mozilla.com/D11527
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
