When queried range starts with a block frame, we cannot compute proper line breaker's rect at its open tag only with the frame's rect because the proper rect should be at the end of previous text frame.
Therefore, this patch makes SetRangeFromFlatTextOffset() return the last text node found at scanning the range. Then, OnQueryTextRect() can compute the first line breaker's rect with it (if there is at least one text node).
However, if the last text node is hidden by CSS or something, this patch won't work. We need to do something in another bug for hidden frame's issue, though. But note that IME typically doesn't request hidden text's rect because neither selection nor composition string is in such range.
MozReview-Commit-ID: 2FFzNoubJ1y
--HG--
extra : rebase_source : b9c4af40b8747f19da8e55434d580e29322c9601
In plain text editor, moz-<br> element is appended for a placeholder of empty line when the text ends with a line breaker. Therefore, when we compute text rects, we need to handle it same as a normal <br> element even though it doesn't cause any text.
MozReview-Commit-ID: 4IXLafU6o0W
--HG--
extra : rebase_source : 5db9c70e3acd40e4f47f35fcf293702ce0fb0295
Although, this patch is pretty big and complicated, but I have no idea to separate this since this rewrites all over the OnQueryTextRect() with new utility methods which are implemented for OnQueryTextRectArray().
Currently, OnQueryTextRect() doesn't support line breaks before block level elements. Therefore, in HTML editors, eQueryTextRect may not work fine if the range includes open tags of block level elements. This causes odd positioning of IME's candidate window in non-e10s mode.
This implements ContentEventHandler::GetLastFrameHavingFlatTextInRange() which scans the given range from last to first. However, this hits wrong NS_ASSERTION() in nsContentIterator::Last(). mLast can be nullptr if there is no content but Init() returns NS_OK even in such case. I think that returning NS_OK is fine because it's not illegal case. Therefore this patch fixes the wrong assertion.
MozReview-Commit-ID: E6OnIA1eMou
--HG--
extra : rebase_source : e44114b6fb0024c2ab7f9101b12335de4b5cc4aa
When the loop in ContentEventHandler::OnQueryTextRectArray() reaches at the end of contents, it should append a caret rect at the end of the contents. That helps deciding popup position of IME when caret is at the end of the contents.
This patch guesses the caret rect with eQueryTextRect event (for avoiding the dependency of native caret position of eQueryCaretRect event handler).
MozReview-Commit-ID: 8cGeHpkzX9g
--HG--
extra : rebase_source : c7adc65ccf0fefa7cb1c3bd0b056dc04f8a85b3e
This is hack for returning better rect for a line breaker caused by non-<br> element. E.g., if a block frame causes a line break, after the last visible character is the best position, i.e., there is |<p>ABC</p><p>DEF</p>| and the caret is after "C", querying next character's rect should be computed with "C"'s rect, rather than computed with next <p> element's border rect.
MozReview-Commit-ID: 7nXt74GGpNf
--HG--
extra : rebase_source : 14807e98cc9a6be22e6168570a299abf0ecaf267
If it returns frames which don't cause text, the caller needs complicated loop. So, it should return only frames which causes some text.
MozReview-Commit-ID: 9gny0w1PUMa
--HG--
extra : rebase_source : 423c7b57355d659e1a5bd96dac35060cae38801c
If line breakers in a text node works as is, e.g., |white-space: pre;| is specified, we need to handle line breakers in text frames too.
This patch handles "\n" in text nodes same as line breakers caused by some elements.
MozReview-Commit-ID: JmXesusFxzR
--HG--
extra : rebase_source : dca28a6e4661eef3c8a102916c451e0f021bf6d5
If the query range starts middle of a line breaker, i.e., "\r[\n", ContentEventHandler::OnQueryTextRectArray() does not need to (in other words, should not) append same rect anymore.
This patch checks if the range starts middle of a line breaker and in such case, skip to append same rect.
MozReview-Commit-ID: H5gdtAakGcP
--HG--
extra : rebase_source : 3afaca4d6e9f09e2054c4a6bd876635cfef6c58c
Some elements causes a line break before itself. In such case, OnQueryTextRectArray() should append one or two rects for such line breakers.
This patch also implements GetLineBreakerRectBefore(). It computes line breaker rect for the given frame. Even if it's a <br> frame, we cannot use its rect because <br> frame height is computed with line height but we need text's height (i.e., font height) and both height and width are 0 if it's in quirks mode and in non-empty line. Therefore, this patch computes it with frame's baseline, font's max-ascent and max-descent.
Although, this patch computes a line breaker rect caused by a open tag of a block level element with block frame's rect. However, it shouldn't be used actually as far as possible. Following patches will kill the path to the hack.
MozReview-Commit-ID: 9cym04j9NH9
--HG--
extra : rebase_source : 3117d68f056dc69550a16f52adade82049ba8277
When eQueryTextRect's query range length is 0 (this may be caused by native IME's bug), it should return caret rect. Therefore, it should redirect such query events to OnQueryCaretRect(). Such IME must want caret rect in such case.
MozReview-Commit-ID: JaUwhw1Cn5G
--HG--
extra : rebase_source : aef43e028fdf19b1e4977ce0d73e3fd700793ba9
ContentEventHandler::OnQueryTextRect() is now too complicated. So, we shouldn't duplicate similar code in OnQueryCaretRect(). When it needs to guess a caret rect from a character rect, we shouldn't compute character rect by itself.
MozReview-Commit-ID: 5G4MzQJzmoV
--HG--
extra : rebase_source : 31f2ec578eeb2af82b8af2d938448eb42afd50ea
This can kill the duplicated code in a lot of places in ContentEventHandler.
MozReview-Commit-ID: BRpBkbXyeBs
--HG--
extra : rebase_source : 98021e68cd0150149e6417c5a8f91979f5baad76
Currently, ContentEventHandler::SetRangeFromFlatTextOffset() sets end point to before a line breaker when the end of queried range is between a set of native line breakers (i.e., "\r]\n" on Windows). This causes unexpected empty range (e.g., "[]\n") when it queries a text rect at [\r]\n.
Therefore, it should select an XP line breaker in such case (i.e., the range should be "[\n]" when it queries "[\r]\n" or "\r[\n]").
Note that we don't need to do anything at setting selection start because it's always aligned to before the line breaker.
MozReview-Commit-ID: 6ht8QNAhibY
--HG--
extra : rebase_source : b7933554c2a5bf51b8faabe3a96d006971510e0a
This patch makes the static methods members of ContentEventHandler because ContentEventHandler::NodePosition is useful for them.
* nsINode* AdjustTextRectNode(nsINode*, int32_t&) -> NodePosition GetNodeHavingFlatText(nsINode* int32_t)
* nsIFrame* GetFirstFrameInRange(nsRange*, int32_t&) -> FrameAndNodeOffset GetFirstFrameHavingFlatTextInRange(nsRange*)
So, this patch avoids unclear in/out arguments of them.
MozReview-Commit-ID: 7yWeIkRdGj
--HG--
extra : rebase_source : 635cec95ee9f3d73f619186925464ae17010e929
GetFirstFrameInRange() uses AdjustTextRectNode() which may return different node before retrieving the result frame. Therefore, the caller may need offset in the new node.
MozReview-Commit-ID: 2AQU5WfahT9
--HG--
extra : rebase_source : c753d34dc2691da2ec25c9f5a6fe17d67af24a70
Returning empty rects for eQueryTextRectArray causes each dispatcher needing to check every rect. It doesn't make sense especially compared with eQueryTextRect.
So, it should ensure that empty rect won't be returned to dispatchers.
MozReview-Commit-ID: CpMqqihzSDf
--HG--
extra : rebase_source : 0343e2eecf5e25043d260157cf4d8b0874e0ceb6
This patch also renames:
EditorInputEventDispatcher -> mozilla::EditorInputEventDispatcher
And some variable names are renamed from aEditor or mEditor to aEditorBase or mEditorBase for making their types clearer.
MozReview-Commit-ID: 2FCXWpLMn8e
--HG--
rename : editor/libeditor/nsEditor.cpp => editor/libeditor/EditorBase.cpp
rename : editor/libeditor/nsEditor.h => editor/libeditor/EditorBase.h
It will use on ContentCache. Also, SetRangeFromFlatTextOffset issue will hanle on another bug.
MozReview-Commit-ID: 9Yu8bLlcZS5
--HG--
extra : rebase_source : c8eba70bdedf303b0fa649c1a609fe6120983e65
extra : histedit_source : 4189807b57ede13c1546e95052fcc298c8581d06
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
Selection's focus and anchor node and offset are stored only for the last range. However, ContentEventHandler needs its first range. Therefore, ContentEventHandler shouldn't refer them if there are two or more selection ranges.
MozReview-Commit-ID: ACflFE3ZrOM
--HG--
extra : rebase_source : 9a2d1ef0e18a07881f77deff579830a4a0c97fc5
TextComposition needs to query first IME selection. Therefore, we need to add support to query special selection range with eQuerySelectedText.
First, WidgetQueryContentEvent::mInput should have mSelectionType which should be initialized with InitForQuerySelectedText() but unfortunately, there is no method for eQuerySelectedText. Therefore, this patch initializes WidgetQueryContentEvent::mInit::mSelectionType with SelectionType::eNormal in its constructor.
Next, ContentEventHandler needs to support to handle eQuerySelectedText with special selection types. However, we need to create 2 paths in some cases, one is for normal selection and the other is for special selections because there are no selection ranges may be usual case for special selections but not so for normal selection. Therefore, ContentEventHandler::InitCommon() becomes a little bit more complicated. ContentEventHandler::mSelection and ContentEventHandler::mFirstSelectedRange is initialized with the specified selection type but normal selection type is also necessary to compute the selection root since the selection root is computed from the first selected range which may not be anywhere if its selection type is not normal.
Finally, ContentEventHandler::OnQuerySelectedText() returns "there are no selections" as succeeded case in special selection type cases.
MozReview-Commit-ID: 9WzUx8b5piw
--HG--
extra : rebase_source : fb07b40748b594d36315f1fc21c0a02ff9f668bb
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : source : bd88a2e478e23edf1845f724a32fef908c8cc007
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : rebase_source : 29961e56b5fe14b244046b3dc52b1f922c206218
During a query selection event, fail if the selection is outside of the
editor's root content. This can happen if the placeholder text in an
input field is somehow selected. The placeholder is in a separate
element outside of the root content.
Also fix a bug in test_imestate, where the selection was not properly
reset at the start of a test.
During a query selection event, fail if the selection is outside of the
editor's root content. This can happen if the placeholder text in an
input field is somehow selected. The placeholder is in a separate
element outside of the root content.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This patch started an attempt to remove nsFrameSelection.h from nsCaret.h
and metastasized into a rather large refactoring patch that removed it
from some other header files as well, and changed nsFrameSelection::HINT
into a global-scope enum with better names. I also converted bools
into CaretAssociationHint in a few places where that was appropriate,
but there are still some more places (GetChildFrameContainingOffset)
where bools need to be converted. I figured this patch was big enough already.
--HG--
extra : rebase_source : cc618ef60e707e1360644340a2648de389383da0
GetGeometry is used in two different ways. Sometimes it's used to get
information about a particular caret. Sometimes it's used to get
information about a particular selection that's not associated with
a caret. Splitting GetGeometry into a non-static version for the former
and a static version for the latter makes this more clear. Also it saves
code since for the latter version we don't have to get an nsCaret first.
--HG--
extra : rebase_source : b7730dac56b308a82b79b175749234c9a92b6f59
Masayuki Nakano
Makoto Kato
Jonathan Watt
Jonathan Kew
Xidorn Quan
Carsten "Tomcat" Book
Jim Chen
Wes Kocher
Kyle Huey
Mark Capella
Botond Ballo
Nathan Froyd
Andrew McCreight
Timothy Nikkel
Andrea Marchesini
Nicholas Nethercote
Andrew McCreight
David Zbarsky
Robert O'Callahan
Steven Michaud