Like EditorBase::InsertTextImpl(), WSRunObject::InsertText() is really messy.
So, it should take same arguments as EditorBase::InsertTextImpl().
MozReview-Commit-ID: 5uKGaxKheRv
--HG--
extra : rebase_source : 49ce0eb7ea25b397b6b1a19f1bc21d711740c043
EditorBase::InsertTextImpl() takes |nsCOMPtr<nsINode>*|, |nsCOMPtr<nsIContent>*|
and |int32_t| as in/out arguments for container, child and offset of the child
in the container. But this makes the callers really hard to read and ugly.
So, we should make the method take |const EditorRawDOMPoint&| argument as input
and |EditorRawDOMPoint*| as out argument.
MozReview-Commit-ID: 2ijIfGl4Zo7
--HG--
extra : rebase_source : b309d9bdc04aac620f138769ba18ad7e4597fe6c
EditorBase::FindBetterInsertionPoint() now use 3 in/out arguments. This is
really ugly and making the callers hard to read. So, let's make it take an
argument whose type is |const EditorRawDOMPoint&| and return other
EditorRawDOMPoint instance.
Additionally, this fixes bugs of text node length checks in the method.
Basically, this shouldn't affect to any actual behavior, though. That is
because text node shouldn't be able to have string longer than INT32_MAX.
MozReview-Commit-ID: FClUQSJzd8c
--HG--
extra : rebase_source : 3e2fbd345015f7068c7e35a94c31731e7936009f
It is no reason to use custom atom instead of nsGkAtoms now, so we should
use nsGkAtoms instead.
MozReview-Commit-ID: 9slsZtLDNKH
--HG--
extra : histedit_source : 8ad70ff1adfa145bc0e8da3c6f43f3dba9b558f1
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
Since if the container is not a container node like a text node or the offset
is same as the length, child at the offset can be nullptr.
MozReview-Commit-ID: DCnFwUjNgk7
--HG--
extra : rebase_source : 48823390645d79db391dcaf64dab59e754b680a5
|selChild| should be a node which is at |curOffset| in |curNode|, however,
it's not updated when |curOffset| is updated by a call of CreateBRImpl(). So,
it should be next sibling of the created br node.
MozReview-Commit-ID: IVfTjVMp3lB
--HG--
extra : rebase_source : fbc355e3c0425a495c78c3c028308dac26617283
Editor sometimes extracts atom to string to compare element name.
It is unnecessary to use atom directly.
MozReview-Commit-ID: FEvyiIeaozs
--HG--
extra : rebase_source : 4418d0c82fa4fedd814b914f2cf3a86d74ad9835
When SplitNode returns nullptr, GetAsText causes crash. So we should check
error before casting by GetAsText.
MozReview-Commit-ID: 8E1OPSRZ2x5
--HG--
extra : rebase_source : 48a067bd080e7a68e9d469c07d3b744508dae91f
1405747.html is kind of same issue. But when editing 1405747.html, the crash doesn't occur. So I keep original HTML by jsfuzzy.
MozReview-Commit-ID: 9BcUkWeBlr5
--HG--
extra : rebase_source : 1bac60293d3b4997a380cf625c6492db22f60160
extra : histedit_source : eae38e2d69e0705545acf1ef1f2d04e7977b8899
GetNodesForOperation returns node array from current selection. So some nodes in this array might have no parent node. We should ignore such as orphans.
MozReview-Commit-ID: 3OK0CUv5QOe
--HG--
extra : rebase_source : 59636177113ad5d3f9789ca22a6a96938e4cf486
extra : histedit_source : fd4fd140a24a8dc5a63fceeb25faba827c317683%2C6ed479239be0a9043d05170231c6613b04cb0d26
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Starting from bug 1297414, HTMLEditor treats <div> container as same as <p>
container at inserting a line break. This new behavior is check in WPT.
So, it's better to use the new behavior for compatibility with other browsers.
However, we're still using <br> as default paragraph separator for backward
compatibility even though this is non-standard behavior.
So, although, the old behavior is odd, we should keep treating them differently
in the backward compatibility mode. Actually, this behavior change causes
an incompatibility problem in Gmail, and may be in other web apps.
MozReview-Commit-ID: INCihKYmcPd
--HG--
extra : rebase_source : 874e41ddf7bbedbea2c7af79285ea79fbc48f0f2
This patch adds an overload to nsIContentIterator::Init which accepts
RangeBoundary objects, and modifies the codepath to avoid using the offset of
the start or end nodes to construct the nsIContentIterator.
MozReview-Commit-ID: 5ZqKeiUunoN
This might be regression by bug 1319340, but there is crash signature from old version. We should check whether focus node and anchor node aren't null.
MozReview-Commit-ID: J7npxN5kC9G
--HG--
extra : rebase_source : e2f19690d529abc1a8e2852a5ed826b0caa39244
This is a typo bug of Bug 1053779 Part 2. ConvertListType might return NS_OK
even if ReplaceContainer doesn't return valid value.
So, to clean up code, we should return Element instead of nsresult since out
parameter of this function is Element only.
MozReview-Commit-ID: 44UHETzcdGy
--HG--
extra : rebase_source : ab76486505cb4e7caea3fb99e11fccd606878f02
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
Removes the nsIDOMHTMLObjectElement XPCOM interface, replacing it with
HTMLObjectElement and FromContent conversion usage.
MozReview-Commit-ID: dmsjSO97uh
--HG--
extra : rebase_source : 9b2c25b8681f754bc34233afccdb6fc5d38f0804
It a stateless wrapper around static methods in nsHTMLTags and nsHTMLElement,
and hence an unnecessary layer of indirection that just adds complexity and
slowness. This patch removes it, cutting almost 300 lines of code.
This requires making nsElementTable.h an exported header, to expose the
nsHTMLElement methods.
--HG--
extra : rebase_source : abbcb8e5001389affbf717092213b898673db07f
Its return value is never used, and most implementations return nullptr anyway.
MozReview-Commit-ID: 8rxC053mmE8
--HG--
extra : rebase_source : 61a0b8b1373396182efd27d3c01b96e5e5541364
After applying part 1 fix, it doesn't pass test_bug430392.html like the following..
1. content is <span contenteditable=false>A</span>[caret] ;
2. [VK_RETURN]
3. content is <span contenteditable=false>A</span><br>; <- whitespace is removed
Since we started to treat readonly text nodes as WSType::special with previous patch, WSRunObject::InsertBreak doesn't convert space (after caret) to NBSP because WSRunObject::InsertBreak does it only when inserted position isn't first text run object.
So even if this is first text run object, space after caret should be converted to NBSP.
MozReview-Commit-ID: Hj0i3wm45c3
--HG--
extra : rebase_source : 2d0ae7c47c6187e56d6c29e8eb48974f7ab7ff72
This bug occurs that WSRunObject::PrepareToDeleteRangePriv() calls WSRunObject::ConvertToNBSP for non-editable text node.
Actually, even if text node isn't editable, WSFragment::mType becomes WSType::text now. So, whitespace only node at the end of contenteditable=false is treated as WSType::normalWS, i.e., treated as editable.
So text node in contenteditable=false should treated as WSType::special which means a non-editable inline object. Then, WSRunObject won't create object chunk of WSType::normalWS for text node in contenteditable=false.
MozReview-Commit-ID: GOjxax8KvDD
--HG--
extra : rebase_source : e5fff30a2710c2021d59ce88bf2698ce4ebe2dfc
With previous change, KeyboardEvent is dispatched even when invisible window
has focus. However, nsRootWindow::GetControllerForCommand() returns controller
for focused window even when the window is invisible because it uses
nsFocusManager::GetFocusedDescendant() to retrieve focused window.
Perhaps, we can assume that users won't expect to do something with invisible
window when they type some keys. Then, nsRootWindow::GetControllerForCommand()
should return controller for visible ancestor window if focused window is
invisible.
This patch makes nsFocusManager::GetFocusedDescendant() can return only visible
descendants. However, it already has a bool argument. Therefore, it should
have a flag instead of adding new flag. Most changes of this patch is replacing
its callers.
Then, nsRootWindow::GetControllerForCommand() and nsRootWindow::GetControllers()
should have a bool flag if it should return controller(s) for visible window.
This patch adds a bool flag for it. Fortunately, the interface isn't scriptable.
Finally, this patch makes nsXBLPrototypeHandler::DispatchXBLCommand() and
EventStateManager::DoContentCommandEvent() retrieve controller for visible
window since they are always handles user input.
MozReview-Commit-ID: GygttTHuKRm
--HG--
extra : rebase_source : 1341273c4606298cb9b890b9312d9f5c8a75d144
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 22bb5d4e3c5138ef832995eaf5716824f4707ffe
extra : source : d40fb20c9a49d0797c0eeae613a04912b12a28f7
As written, these functions will leak if they are passed strings that don't
match static atoms. In practice, all strings passed *do* match static atoms,
but let's fix it anyway in case that changes in the future.
--HG--
extra : rebase_source : 01685428e7dfc577e63bb6423382817359623151
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 0c307639c3626af3b6b43e05d3ee73d08b3f47ce
In the old design, EditorBase::mRootElement is initialized when
nsIEditor::GetRootElement() is called. Therefore, EditorBase::GetRoot()
calls if mRootElement is nullptr.
However, mRootElement is now initialized when EditorBase::UpdateRootElement()
is called and it's always initialized when EditorBase::Init() is called.
So, EditorBase::GetRoot() doesn't need to call nsIEditor::GetRootElement()
anymore.
MozReview-Commit-ID: 6dNEJaGNMZe
--HG--
extra : rebase_source : ed29488cfd1434fb200387706ca5a96cb2185090
When using contenteditable with spellchecker (it is by default), spellchecker will be initialized by mozilla::EditorEventListener::Focus. This method will call nsEditorSpellCheck::UpdateCurrentDictionary, but this method seems to be slow.
DictionaryFetcher::Fetch gets nsIContentPrefService2 that is implemented by JavaScript, so we should create nsIContentPrefService2 out of Fetch method.
MozReview-Commit-ID: 1fxug0sqD72
--HG--
extra : rebase_source : c46a54f9fc811aace20c54c4a3e468a83c2530d2
It's a bit strange for the editor to distrust the parser service in this way.
The double-checking seems unnecessary, especially given that it is *buggy*: it
incorrectly includes `col`, `colgroup`, and `legend` as block elements, but
excludes `pre`. (It must only be called in situations where these
incorrectly-classified elements are not passed in, otherwise it would have
triggered by now.) So this patch removes it.
The patch also removes `li` and `pre` from the IsAnyOfHTMLElements() test in
HTMLEditor::NodeIsBlockStatic. Contrary to what the comment in
NodeIsBlockStatic() says, they *are* identified as block elements by the parser
service.
--HG--
extra : rebase_source : c9bb3c9e07320fafed17942229c316f41ac2a0a6
editor/reftests/input-text-onfocus-reframe-ref.html is sometimes failed due to "image comparison, max difference: 1, number of differing pixels: 1".
As long as I check both images, I don't know why focus ring is different. But this is 1 pixel only diff, so we should use fuzz-if.
MozReview-Commit-ID: 5SrjorXEBW
--HG--
extra : rebase_source : d6fbb2f3a5ea2bff5ee6c2b39909831830f5d47c
EditorBase::EndPlaceholderTransaction() has hidden caret. However, it doesn't
do it anymore. However, bug 805697 didn't remove unnecessary code that
retrieves and hold nsIPresShell and nsCaret. This patch removes them.
MozReview-Commit-ID: Eh9pbf8p2bZ
--HG--
extra : rebase_source : e766906089af1cd3c6efa95b82e3b126ae097ab2
GetFirstSelectedCell and GetNextSelectedCell allow that 1st parameter is nullptr when current range is unnecessary. So we should use nullptr when it is unused.
MozReview-Commit-ID: BuI7ds47h0U
--HG--
extra : rebase_source : 4cb67aa15c5b5a7692c7e5eb43976c8e7a7884e4
Except to nsTextServicesDocument.cpp, we replace nsIDOMRange::GetStartContainer and nsIDOMRange::GetEndContainer with nsRange::GetStartContainer and nsRange::GetEndContainer.
Since nsTextServicesDocument.cpp still uses a lot of nsIDOMNode, I will change it by new bug.
MozReview-Commit-ID: 9x1oajmabca
--HG--
extra : rebase_source : c22072a39c907df631025a423c6302df2047e824