Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
And make sure the caret ends up being visible, rather than _not_
visible.
This should be implementable on windows as well. It seems macOS doesn't
have a timeout thing.
Differential Revision: https://phabricator.services.mozilla.com/D122132
A bit of a wallpaper, but it's silly to crash with a null deref here. If
there's no selection there's nothing to invalidate really.
We already null-check it effectively when aOverrideNode is null.
Differential Revision: https://phabricator.services.mozilla.com/D97960
Currently, there's no way to tell whether the SIDEWAYS bit is set from
`writing-mode:sideways-*` or `writing-mode:vertical-*; text-orientation:sideways;`.
To be able to tell them apart, split SIDEWAYS bits into VERTICAL_SIDEWAYS
and TEXT_SIDEWAYS. This is needed by my proposed solution in bug 1102175.
Also, provide convenience methods related to sideways writing-mode, and replace
obscure checks in the codebase.
Note that we don't have the use cases to distinguish vertical-rl from
sideways-rl in layout, but for the completeness, IsSidewaysLR() is still
defined.
Differential Revision: https://phabricator.services.mozilla.com/D46321
--HG--
extra : moz-landing-system : lando
There is the following usage of nsIPresShell:
```
nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShellWeak);
```
So, for changing this to:
```
RefPtr<PresShell> presShell = do_QueryReferent(mPresShellWeak);
```
PresShell should have its own IID.
Differential Revision: https://phabricator.services.mozilla.com/D29197
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
This patch makes `nsFrameSelection` treat `mozilla::PresShell` directly and
rename `nsFrameSelection::GetShell()` to `nsFrameSelection::GetPresShell()
because of avoiding confusion between `PresShell` vs. `DocShell`.
Differential Revision: https://phabricator.services.mozilla.com/D25719
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
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
Mike Hommey
Greg Tatum
Emilio Cobos Álvarez
Butkovits Atila
Masayuki Nakano
Kagami Sascha Rosylight
Dorel Luca
Marian-Vasile Laza
Mirko Brodesser
Narcis Beleuzu
Ting-Yu Lin
Kagami Sascha Rosylight
Cameron McCormack
Noemi Erli
Gurzau Raul
Ryan Hunt
Sylvestre Ledru
Brindusan Cristian