All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
I'm pretty sure the FIXME I left in the outline-style code is a bug,
but I want to clean this up further and I didn't want to fix it without adding
a test.
Differential Revision: https://phabricator.services.mozilla.com/D12859
This is consistent with what we do for non-stacking-contexts. The
GetCaretFrame() == child check may be able to go away, I'm not sure, so I've
left it for now.
Differential Revision: https://phabricator.services.mozilla.com/D13384
In particular, in nsCharClipDisplayItem::IsSelected() we know that
the frame must be a nsTextFrame (or nsContinuingTextFrame) which
means nsTextFrame::IsFrameSelected() can be called directly now.
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
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
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.
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
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
In this case aAncestor is an SVGOuterSVGFrame, and aItem is a transform item for
its AnonChildFrame.
I'm not sure if it's quite expected to have such a frame generating a
transform...
Let me know if not and I can try to dig more, but this looks intentional given
the comment in nsSVGOuterSVGAnonChildFrame.
Differential Revision: https://phabricator.services.mozilla.com/D10955
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
In bug 1488300 xidorn make us kick off loading of masks/filters/clipPaths in
resource documents when the style context is set so that the 'load' event
will be blocked until they load. I missed that in 5177bb8cb2ce (bug 1494355)
where we stopped creating the SVGFilterObserverList in
SVGObserverUtils::GetEffectProperties since I missed that creating that object
looks up the target element (without observing it), which triggers loading of
external resources as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D7188
We're traversing primary frames, which are first continuations, so we can't
start from a continuation and expect to get to it. Add an assertion that would
catch further fishyness.
Differential Revision: https://phabricator.services.mozilla.com/D6672
In the button case we have a ::-moz-button-content pseudo-element, but this is
also an issue for tables and such.
These are supposed to be implementation details, so avoid looking at them for
preserve-3d.
I don't know how I didn't think of this on the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D6131
In the button case we have a ::-moz-button-content pseudo-element, but this is
also an issue for tables and such.
These are supposed to be implementation details, so avoid looking at them for
preserve-3d.
I don't know how I didn't think of this on the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D6131
In the button case we have a ::-moz-button-content pseudo-element, but this is
also an issue for tables and such.
These are supposed to be implementation details, so avoid looking at them for
preserve-3d.
I don't know how I didn't think of this on the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D6131
