e5b7ceb6f27e8ebee9136e6a14a9ed629ff116cf: Bug 1286464 part.19 ContentEventHandler::OnQueryTextRect() should handle the case when queried range starts from the end of mRootContent r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 19:24:50 +0900 - rev 398653
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.19 ContentEventHandler::OnQueryTextRect() should handle the case when queried range starts from the end of mRootContent r?smaug First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail. This patch fixes all cases when the start offset of queried range reaches the end of mRootContent. 1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect. 2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter(). 3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height. 4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3. MozReview-Commit-ID: FS9cWJQ39DK
b50a88bb0b46cd08c7b54461e0cc70c9b8063811: Bug 1286464 part.18 ContentEventHandler::OnQueryTextRectArray() should compute line breaker's rect with the last character's node when the start of queried range is a line breaker and it's caused by a block frame r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 19:05:35 +0900 - rev 398652
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.18 ContentEventHandler::OnQueryTextRectArray() should compute line breaker's rect with the last character's node when the start of queried range is a line breaker and it's caused by a block frame r?smaug Similar to OnQueryTextRect(), OnQueryTextRectArray() should compute a line breaker's rect with the last character when it's the first character in queried range and not caused by <br> frame. MozReview-Commit-ID: CGDHbcrc6zB
876f1008a691ac59f3decd966d004e718db04cf2: Bug 1286464 part.17 ContentEventHandler::OnQueryTextRect() should compute a line breaker's rect from the last text frame if the queried range starts with a block frame r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 18:11:11 +0900 - rev 398651
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.17 ContentEventHandler::OnQueryTextRect() should compute a line breaker's rect from the last text frame if the queried range starts with a block frame r?smaug 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
fe6c18cf1be61fc8a0022ef1df48022ea90924e8: Bug 1286464 part.16 Rename ContentEventHandler::Get*FrameHavingFlatTextInRange() to ContentEventHandler::Get*FrameInRangeForTextRect() and make them treat a moz-<br> element as a normal <br> element because it doesn't cause text but needs to compute text rect in the last empty line r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 02 Aug 2016 14:00:32 +0900 - rev 398650
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.16 Rename ContentEventHandler::Get*FrameHavingFlatTextInRange() to ContentEventHandler::Get*FrameInRangeForTextRect() and make them treat a moz-<br> element as a normal <br> element because it doesn't cause text but needs to compute text rect in the last empty line r=smaug 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
3c236b4dacb5344e41c420d304b8da9d49d12c49: Bug 1286464 part.15 Rewrite ContentEventHandler::OnQueryTextRect() with new utilities like ContentEventHandler::OnQueryTextRectArray() r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 17:38:21 +0900 - rev 398649
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.15 Rewrite ContentEventHandler::OnQueryTextRect() with new utilities like ContentEventHandler::OnQueryTextRectArray() r?smaug 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
6f5b57cf625b5f857bd5981087d23448d55b03b3: Bug 1286464 part.14 When ContentEventHandler::OnQueryTextRectArray() reaches the end of query range, it should append caret rect at the end of the content r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 16:51:49 +0900 - rev 398648
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.14 When ContentEventHandler::OnQueryTextRectArray() reaches the end of query range, it should append caret rect at the end of the content r=smaug 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
dbdc0bcfa881dc7dab77d3bef1dec1e58e6fdf06: Bug 1286464 part.13 ContentEventHandler::OnQueryTextRectArray() should guess a line breaker's rect with previous character's rect if it's available r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 14:31:37 +0900 - rev 398647
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.13 ContentEventHandler::OnQueryTextRectArray() should guess a line breaker's rect with previous character's rect if it's available r=smaug 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
39b54f3b0aa0b0e0e1ac05775ca18fe2a3ea0336: Bug 1286464 part.12 ContentEventHandler::GetFirstFrameHavingFlatTextInRange() should return only frames whose content causes text r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 21 Jul 2016 17:45:17 +0900 - rev 398646
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.12 ContentEventHandler::GetFirstFrameHavingFlatTextInRange() should return only frames whose content causes text r=smaug 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
75a3b2774bad424e91861a294d1cfee15254f313: Bug 1286464 part.11 nsTextFrame::GetCharacterRectsInRange() shouldn't compute character rect at the first character in next nsTextFrame r=jfkthame draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 21 Jul 2016 16:24:37 +0900 - rev 398645
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.11 nsTextFrame::GetCharacterRectsInRange() shouldn't compute character rect at the first character in next nsTextFrame r=jfkthame nsTextFrame::GetCharacterRectsInRange() handles a character at the end offset of its content as in it. However, it causes odd result when the caller wants first text rect in the next nsTextFrame. E.g., if end of query range is at the next nsTextFrame's first character, currently, it returns the last character as in same line. So, it should stop handling next frame's first character as in it. MozReview-Commit-ID: 7WteerisrZp
bd7f8cfb3a560d16732e7f8db977d34109dbae14: Bug 1286464 part.10 ContentEventHandler::OnQueryTextRectArray() should append same rects for following characters of a line breaker in nsTextFrame r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 14:06:30 +0900 - rev 398644
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.10 ContentEventHandler::OnQueryTextRectArray() should append same rects for following characters of a line breaker in nsTextFrame r=smaug 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
9d9efaadeaa47c7572ac376e2db8495abe131054: Bug 1286464 part.9 ContentEventHandler::OnQueryTextRectArray() shouldn't append same rect for following character of a lien breaker when the query range starts from middle of the line breaker r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 13:53:08 +0900 - rev 398643
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.9 ContentEventHandler::OnQueryTextRectArray() shouldn't append same rect for following character of a lien breaker when the query range starts from middle of the line breaker r=smaug 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
714242a88bc860850d16dcbb7224ace9fcd4b467: Bug 1286464 part.8 ContentEventHandler::OnQueryTextRectArray() should handle line break before a node r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 13:36:22 +0900 - rev 398642
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.8 ContentEventHandler::OnQueryTextRectArray() should handle line break before a node r=smaug 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
434210311aaaad4354a2c91f0372ec1f4561010b: Bug 1286464 part.7 ContentEventHandler::OnQueryTextRect() should redirect the query event to OnQueryCaretRect() if its query range is empty r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 25 Jul 2016 23:19:53 +0900 - rev 398641
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.7 ContentEventHandler::OnQueryTextRect() should redirect the query event to OnQueryCaretRect() if its query range is empty r=smaug 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
eff622fa15ca6deba150a582fb9a1a2f3f883a0c: Bug 1286464 part.6 ContentEventHandler::OnQueryCaretRect() should use eQueryTextRect event when it needs to guess the caret rect r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 29 Jul 2016 00:37:09 +0900 - rev 398640
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.6 ContentEventHandler::OnQueryCaretRect() should use eQueryTextRect event when it needs to guess the caret rect r=smaug 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
40b608093ac5b8deb78cc86c8a5e06bb3acde0cb: Bug 1286464 part.5 Create ContentEventHandler::EnsureNonEmptyRect() for query various rect event handlers r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 13:01:17 +0900 - rev 398639
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.5 Create ContentEventHandler::EnsureNonEmptyRect() for query various rect event handlers r=smaug This can kill the duplicated code in a lot of places in ContentEventHandler. MozReview-Commit-ID: BRpBkbXyeBs
42d2a7f90d5d750f8532b4feca67e317268db0bc: Bug 1286464 part.4 ContentEventHandler::SetRangeFromFlatTextOffset() should set end of the range to after a line break when the range is end between a set of native line breakers r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 28 Jul 2016 17:23:47 +0900 - rev 398638
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.4 ContentEventHandler::SetRangeFromFlatTextOffset() should set end of the range to after a line break when the range is end between a set of native line breakers r=smaug 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
f8d1907bc2d692809ec57088c87be1f3d92662cb: Bug 1286464 part.3 Make static methods, AdjustTextRectNode() and GetFirstFrameInRange(), members of ContentEventHandler r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 12:43:40 +0900 - rev 398637
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.3 Make static methods, AdjustTextRectNode() and GetFirstFrameInRange(), members of ContentEventHandler r=smaug 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
5abb618df408be22e1fec8682ef3c4d727b9b4ce: Bug 1286464 part.2 GetFirstFrameInRange() should return node offset since it may return different node's frame r=m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 14 Jul 2016 22:57:00 +0900 - rev 398636
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.2 GetFirstFrameInRange() should return node offset since it may return different node's frame r=m_kato 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
e7470fa53cb6b4da2d854eb9702f19783d92bd11: Bug 1286464 part.1 Cleaning up ContentEventHandler::OnQueryTextRectArray() r=m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 14 Jul 2016 22:46:37 +0900 - rev 398635
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.1 Cleaning up ContentEventHandler::OnQueryTextRectArray() r=m_kato MozReview-Commit-ID: BDLkQLrzoUI
61623acdcb904d0d5f2afa945d42312704f4a3b4: Bug 1286464 part.0 Add eQueryTextRect tests for line breakers r=smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Sat, 30 Jul 2016 22:00:30 +0900 - rev 398634
Push 25590 by masayuki@d-toybox.com at Tue, 09 Aug 2016 15:40:38 +0000
Bug 1286464 part.0 Add eQueryTextRect tests for line breakers r=smaug MozReview-Commit-ID: 2SxNlyjc4KM
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip