This patch adds tests for the core aspects of the client authentication code,
mainly to ensure the client auth process even works.
MozReview-Commit-ID: DzV4BuwlrDE
--HG--
extra : rebase_source : 43224d3159964f02b175e8c54491b2cabba2cb8a
Also, is a ConEmu preferences file which automatically points a newly installed ConEmu to the newly installed MSYS2.
MozReview-Commit-ID: FBeMat4SYjK
--HG--
extra : rebase_source : 83d8f03a6cc011215fe58745c93afdf90162dc58
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
--HG--
extra : rebase_source : cb2ea4cfb4c8d5c85a4dd7498aa11bd86b61c2ef
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
--HG--
extra : rebase_source : 7e7cad1aebc4b1c675360a1a1ff6e704d17c4e5c
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
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
--HG--
extra : rebase_source : 97653f1ed04a6a03373cd53613d92aba45fbe38b
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
Nothing depends on the value of the mark bit now.
MozReview-Commit-ID: 9k06XdtR9KB
--HG--
extra : rebase_source : 57c54960af71c754663575a02c4fc319dd13b505
This adds a heap allocation in
XPCNativeScriptableSharedMap::GetNewOrUsed() on the fast
path. Hopefully that code is not hot enough for it to matter. I could
work around this if needed, but it would be ugly.
mNativeScriptableSharedMap has a weak pointer to
XPCNativeScriptableShared. I moved this removal from
XPCJSRuntime::FinalizeCallback() to the dtor.
There are two types of scriptable: one is a dummy one created in
GetNewOrUsed() to do a lookup, and the other is a fully filled out
one. The dummy one is not added to the hashtable, and may have had its
name stolen if we created a new scriptable. The latter makes it so
that you crash if you try to look it up in the hashtable anyways, so
this patch only looks up fully filled out scriptables.
This patch also removes MOZ_COUNT_CTOR/DTOR because they are not
needed for refcounted classes.
MozReview-Commit-ID: GeG0pAYqXpR
--HG--
extra : rebase_source : ac67f7573f0ad0b2bb1916fb4d6fcd30e64a40f1
We need to update mLastComputedValue while processing events that occur at the
same time rather than just skipping over them.
MozReview-Commit-ID: LuxSK6PHFHv
--HG--
extra : rebase_source : be323da2a50ea32838aef322267115d153a14c3d
The code that checks to see whether or not we should flip the remoteness of a browser
before loading the session state into it wasn't accounting for the fact that oftentimes,
restoreImmediately isn't included, so it's undefined, which coerces to "false-y".
This caused us to very quickly destroy a TabParent, very soon after creating it. In
some cases, the IPC layer seems to not like that, and throws an OnChannelError,
which causes the TabParent ActorDestroy method to be called with an abnormal
shutdown reason, which causes the tab crash observer to fire, which bubbles the
tab crash event.
We should probably make the IPC layer more resilient to this sort of thing, but
we should also probably not flip remoteness when we really don't need to.
Now instead, when restoring a tab, we detect whether or not it's going to
be restored automatically in the near future. If it's not going to be
restored automatically, and the browser is remote, we flip its remoteness -
otherwise we leave it alone.
MozReview-Commit-ID: 5AmPHvzDZlX
--HG--
extra : rebase_source : 9e152c2f1106eda76702bd3ed4cf48e9703e05c8
New eQueryTextRectArray causes a lot of assertions in various automated tests. The cause is that nsTextFrame::GetCharacterRectsInRange() calls gfxSkipCharsIterator::AdvanceOriginal(1) at the end of the |for| loop *without* checking if the iterator has already reached to the end.
MozReview-Commit-ID: 3KFxA11uOUc
--HG--
extra : rebase_source : 407c47897cad8c2e4929ed1226073302faaecee2
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 makes ContentCache store previous character's rect of selection anchor and selection focus because if caret is at end of a line, IME may query the last character of the line.
MozReview-Commit-ID: 5X1K8KtrYfl
--HG--
extra : rebase_source : 403e4c993b48a832d50b4f44738c5b5c6d5ce085
Drew Willcoxon
Cykesiopka
Sebastian Hengst
Nathan Hakkakzadeh
Masayuki Nakano
Tom Tromey
Andrew McCreight
Dan Minor
Nicolas Chevobbe
Mike Conley
Shih-Chiang Chien
Henrik Skupin
Dave Townsend
Rob Wu
Jarda Snajdr
Andrew Swan
Bob Silverberg