When returning the column or row index of a given cell, guard against the column count being 0 or the given index being out of bounds of the current grid or table. The MSAA code already did this previously, but now the upper bounds check has been moved to the base classes and an additional guard for the column count been put in place so a division by 0 crash canot happen.
A return value for RowIndexAt and ColIndexAt of -1 indicates an error condition. ATK will automatically deal with this, and the IA2 code has been adjusted to check for this and return an invalid argument error in such cases, too.
Differential Revision: https://phabricator.services.mozilla.com/D18931
--HG--
extra : moz-landing-system : lando
When getting the cell-index object attribute, now take into account that the row index might be invalid, and bail if that's the case. This should prevent negative index values which were one of the causes of Occasional crashes on Linux with weirdly formed tables like in Gmail.
Differential Revision: https://phabricator.services.mozilla.com/D18546
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Previously, if we had children a, b, c, and d, then removed b, the group position for c and d would potentially be marked as dirty, but a would not. This caused the check for the availability of previous group info to return outdated information.
This patch now always forces the update of all children's group position when a children move has occurred, since it potentially affects all the children, not just the ones after it. In addition, accGroupInfo::Update() now checks if the previous and next siblings that are being used as shortcuts have dirty group info, and are being used only if they do not.
Differential Revision: https://phabricator.services.mozilla.com/D16059
--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.
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : source : 415f827cb9ce211c48b0c6625e917582bc81fd3a
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--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
(Unless there were other profiler actions, as I'm not sure yet whether it would
be safe to skip them when the profiler is paused; another bug should
investigate that.)
Differential Revision: https://phabricator.services.mozilla.com/D11308
--HG--
extra : moz-landing-system : lando
Made IsTableCell() only check the generic type, not the ARIA map entry that gets checked in HasGenericType. This prevents the crash and also fixes IsTableCell() and AsTableCell() not being in sync.
Differential Revision: https://phabricator.services.mozilla.com/D10713
--HG--
extra : moz-landing-system : lando
If html:form has a name given via ARIA, expose it as a landmark to platform APIS that require it. At the time of this submission, this is the case for ATK.
Differential Revision: https://phabricator.services.mozilla.com/D9552
--HG--
extra : moz-landing-system : lando
The issue was specific to content insertion directly under a shadow root, the
rest should work (see bug 1427825 for the fix for other similar occurrences).
The removal of the aContainer argument follows the same pattern as bug 1442207.
Differential Revision: https://phabricator.services.mozilla.com/D6431
Sometimes, when cells have display:block, and a different cell in the same row has a column span, our index methods did not take these into account. Also, when regular tables encounter such a cell, index calculation failed.
Differential Revision: https://phabricator.services.mozilla.com/D7867
--HG--
extra : moz-landing-system : lando
This is preparation of the last patch. Even if no editor is clicked with
middle button, we need to do:
- collapse Selection at the clicked point.
- dispatch "paste" event.
Therefore, HandleMiddleClickPaste() should dispatch ePaste event by itself
and each editor methods should have a bool argument which the caller wants
ePaste event automatically.
Note that Chromium dispatches "paste" event and pastes clipboard content
into clicked editor even if preceding "auxclick" event is consumed.
However, our traditional behavior is not dispatching "paste" event nor
pasting clipboard content. Unless Chromium developer keeps their odd
behavior, we should keep our traditional behavior since our behavior is
conforming to DOM event model.
Differential Revision: https://phabricator.services.mozilla.com/D7854
--HG--
extra : moz-landing-system : lando
This can easily be reproduced if the ancestor being owned has role="presentation", but there are other cases as well.
If we don't prevent this, we end up with a loop.
Differential Revision: https://phabricator.services.mozilla.com/D4051
--HG--
extra : moz-landing-system : lando
When dealing with an editor which contains multiple accessibles, the previous spelling error range might be in a previous accessible, not the accessible currently being queried.
In this case, DOMPointToOffset will return the length of this accessible.
Previously, we weren't checking for this and were overriding the start offset of the returned range regardless, resulting in broken offsets.
Now, we leave the start offset alone in this case.
Differential Revision: https://phabricator.services.mozilla.com/D3960
--HG--
extra : moz-landing-system : lando
User may paste a lot with pressing Accel+V for a while (i.e., with auto repeat).
So, calling nsIEditor::Paste() may be in a hot path and we can now make
non-virtual public method with AsHTMLEditor().
Differential Revision: https://phabricator.services.mozilla.com/D2993
--HG--
extra : moz-landing-system : lando
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
nsIEditor::GetDocumentIsEmpty() is a virtual code and there is non-virtual
method, TextEditor::IsEmpty(). So, any callers in C++ should use
TextEditor::IsEmpty() instead.
MozReview-Commit-ID: CQE8LP6XI96
--HG--
extra : rebase_source : e0027c3d71856adcd5fa7820bf936a6b405560c5
For example, <input type="range"> maps to role="slider", so aria-valuetext should be supported.
MozReview-Commit-ID: IYBVTHP3ZLo
--HG--
extra : rebase_source : 906dfacf92d040abf97b46ff67bafbabc5c9a1ea
nsIAccessibleText.setSelectionBounds should accept a start offset that is larger than an end offset. This is an indica tion that it is a reverse selection, and the caret should be at the start of the selection.
This should also be consistent with how multiple range selections work interactively - the caret should re
main at the last offset reached.
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
This condition is rare and does indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing this as a result of this crash, so it causes user pain without any gain to us.
MozReview-Commit-ID: GacAQDbhB0h
--HG--
extra : rebase_source : 478ec67da378ff763c0e0d8a998de1956b51b85b
According to existing comments, TextEditor::TypedText() and
HTMLEditor::TypedText() are intentional bottleneck to debug. However, only
for that purpose, it and its internal methods are made virtual. This really
doesn't make sense.
So, this patch creates TextEditor::OnInputText() for callers of TypedText()
with non-empty string, TextEditor::OnInputParagraphSeparator() for callers
of TypedText() with eTypeBreak (Enter key or insertParagraphSeparator),
HTMLEditor::OnInputLineBreak() for callers of TypedText() with eTypeBR
(Shift + Enter or insertLineBreak). Additionally, this creates internal
non-virtual methods for XPCOM methods which are used as internal methods of
TypedText(). One is InsertTextAsAction() for nsIPlatintextEditor.insertText().
the other is InsertParagraphSeparator() for nsIPlaintextEditor.insertLineBreak().
Although those new methods are not have "WithTransaction" postfix, they must
be clearer they'll use transactions since user input and actions should be
undo-able.
MozReview-Commit-ID: AmOkMqovIKA
--HG--
extra : rebase_source : 9c0f4b25fa2a36ad2f3394f72eb290824c31d82a
First, EditorBase::DeleteSelection() is never used since
TextEditor::DeleteSelection() overrides it but does not call it. So, this patch
makes EditorBase::DeleteSelection() only returns NS_ERROR_NOT_IMPLEMENTED.
Next, EditorBase::DeleteSelectionImpl() actually removes content for
TextEditor::DeleteSelection(). So, it should be named as
DeleteSelectionWithTransaction(). However, it'll be done in the following
patch. On the other hand, its callers are EditorBase::HandleKeyPressEvent()
and EditorBase::DeleteSelectionAndPrepareToCreateNode(). Fortunately, they
can be moved to TextEditor simply. Therefore this patch moves the methods
to TextEditor for making related methods in a place.
Then, we can make the implementation of nsIEditor::TextEditor() as a non-virtual
method, TextEditor::DeleteSelectionAsAction().
MozReview-Commit-ID: KXFDhW3G9lA
--HG--
extra : rebase_source : 15986979279b2cae3b61cda1bf6bf3d9e4987f3f
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
And likewise for AttrCharacteristics::attributeName.
MozReview-Commit-ID: DwGzWCCKcVP
--HG--
extra : rebase_source : ac595af0b0da2cee36b5aecf4474880fbe993f11