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
There aren't any consumers for the third state, so `checked` is enough.
MozReview-Commit-ID: BpcQX2acA6C
--HG--
extra : rebase_source : f43c9fbe8d774208d203e4d819f39d3d99da05ff
Bug 1421018 intended to block the Ask.Com Toolbar (tbnotifier.exe).
This is basically malware and is responsible for a huge number of unnecessary accessibility instantiations.
However, there seems to have been some confusion and we ended up blocking tbnnotifier.exe instead.
This changes that block to tbnotifier.exe.
MozReview-Commit-ID: 2gZF8sYeGtb
--HG--
extra : rebase_source : 3d14a24c12748edfc31ddf7dac51bca491abd744
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
These events were a hack implemented in bug 703198.
At that time, JAWS required focus events for selection changes in a collapsed combo box.
However, these events also fire for expanded combo boxes.
This is problematic with e10s because now, for an expanded combo box, the real focus events come from the XUL dropdown implemented in the parent process, which is not associated with the document a11y tree in any way.
JAWS seems to cope just fine with value changes for Firefox combo boxes now and VFO have agreed that this is the correct path forward.
MozReview-Commit-ID: Iefop25bFe0
--HG--
extra : rebase_source : a86e5d73d560853bb50e1d8e3bbd11431aba8eb0
In the e10s implementation, Accessible::NativeState for the options doesn't include the invisible state. (It does with e10s disabled.)
In HTMLSelectOptionAccessible::NativeState, rather than just flipping (xor) the invisible state, absolutely ensure it gets removed. We don't want to *add* the invisible state if it isn't there.
This allows group position info to be calculated correctly.
MozReview-Commit-ID: LPEVhOOm2NT
--HG--
extra : rebase_source : 3091ca1826b216bb7c91eb62aafc16f79b786272
Much in the spirit of bug 1442207.
They're not only unneeded, and cheap to get, but also we call them
inconsistently with the light DOM and flattened tree parent (like ContentRemoved
for display: contents), so they're really confusing, and kind of a footgun.
MozReview-Commit-ID: 9u3Kp8Kpp5i
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
