This was an oversight in bug 1520154. We kept the -moz- version in the specified
value but not the computed value.
That's a very peculiar way of making aliases work. This makes them work
consistently as many other aliases instead.
Also, add an assert that would've caught this much much earlier.
Differential Revision: https://phabricator.services.mozilla.com/D40063
I want to do this so that I can get rid of Either<>. The reasons for getting rid
of either are multiple:
* It doesn't generate as nice C++ code using cbindgen.
* It isn't that nice to use either from Rust.
* cbindgen has bugs with zero-sized types.
I started using this for ColorOrAuto and a few others, for now.
Differential Revision: https://phabricator.services.mozilla.com/D19844
The only reason it was on style_traits is so that they could use it from some
other crates, but Servo eventually ends up getting the value from an integer, so
may as well pass it around and do that in the end of the process anyway.
Differential Revision: https://phabricator.services.mozilla.com/D16557
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
It's only used in contenteditable.css, and same usage in comm-central. That
sheet is loaded as a ua sheet so let's restrict it to that. No relevant
external usage either. This value was introduced in bug 1181130.
Differential Revision: https://phabricator.services.mozilla.com/D11584
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
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
Bug: 1455576
Reviewed-by: emilio
MozReview-Commit-ID: LI7fy45VkRw
This more concrete wrapper type can write a prefix the very first time something
is written to it. This allows removing plenty of useless monomorphisations caused
by the former W/SequenceWriter<W> pair of types.
