Holding a weak pres context pointer across stuff that does flushes is dangerous.
Hopefully, we just poke at it when we find a frame (thus a pres context should
be around, and it rather be the one that we started poking at).
I think it'd be better to just not keep the member around, since frames can
reach the pres context easily.
MozReview-Commit-ID: HcepvzcSsaH
--HG--
extra : rebase_source : 5d0ffb1502e64f8010b7aea714a4caf762c9a95e
This allows us to maintain the pre-existing but not-asserted-before invariant of
not doing layout on documents in the BFCache.
The simpler fix here is something like:
if (nsIDocument* doc = mPresShell->GetDocument()) {
doc->FlushPendingNotifications();
}
But referencing the document looks cleaner on most callsites I think. I can just
do the above if you prefer.
MozReview-Commit-ID: L4pTRW3eMAf
--HG--
extra : rebase_source : 466d3eee973f2f14ce0964162e5f7f2f1c2bfc63
(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
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
There is no reason to keep StartBatchChanges and EndBatchChanges in nsISelectionPrivate since this is noscript method. And if moving it to Selection, we can remove virtual keyword.
MozReview-Commit-ID: Go6njiW3r2x
--HG--
extra : rebase_source : cb5bfce8312de7d49496e5f841e9786ff16102f6
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
When setting value of <input type="text">, nsTextEditorState removes all
ranges of normal selection first. Then, TextEditor sets the value. Finally,
TextEditor collapses the selection at the end of the text.
In bug 1386471, we got that there are some problems to remove the call of
Selection::RemoveAllRanges() in nsTextEditorState. Therefore, we need another
approach to improve Selection::Collapse().
The approach of this patch is, when removing all ranges from normal selection,
Selection can cache an nsRange instance if there is an instance which is not
referenced from other than the Selection (i.e., it'll be removed when
Selection::Clear() is called). Then, Selection::Collapse() can reuse it. With
this fix, Selection::Collapse() can reduce allocation cost and may reduce some
other cost like adding it to mutation observer.
However, keeping nsRange instance may cause increasing mutation observer's cost
since nsRange will be adjusted its start node/offset and end node/offset with
mutation observer to guarantee that the range is always valid. So, we can
cache such range only when the caller (or its callee) will set selection range
later. Therefore, this patch adds Selection::RemoveAllRangesTemporarily()
and make only nsTextEditorState::SetValue() and
ContentEventHandler::OnSelectionEvent() use it.
MozReview-Commit-ID: FjWrbz4S1ld
--HG--
extra : rebase_source : 83677640525e0b1a84bdd7fce63ff4704b9cc22b
nsIContentIterator::Init() takes nsRange but it's too expensive for some users.
So, there should be another Init() which can be specified a range in DOM tree
with 2 pairs of nsINode* and uint32_t.
MozReview-Commit-ID: 6JXic0KOM2d
--HG--
extra : rebase_source : 28ff355a2aa0dcb5d65495806ef8c67f1da642ea
Allocating and initializing nsRange is too expensive especially for temporary
use. However, ContentEventHandler uses nsRange only for representing two DOM
points. So, it should use simpler helper class, RawRange, for reducing some
unnecessary runtime cost.
Note that this still uses nsRange for initializing nsIContentIterator. This
will be fixed by the following patch.
MozReview-Commit-ID: 5TUy6yJf7HA
--HG--
extra : rebase_source : c4eb58e8f37c408c75479e6961ba9225f8bcee77
When the start node is a non-container node (i.e. <br>), and the start
offset is 0, we should not include a newline character for the node. For
example, for this range,
> <br/>hello
> \___/
the start node/offset is (<br/>, 0) and end node/offset is ("hello", 1).
The calculated range offset should be 0, and the range length should be
2: 1 for the <br/> newline character plus 1 for "h".
The patch also ensures this behavior for pre-mode nsContentIterator, for
both start and end node adjustments. For start nodes, we include any
non-container nodes with offset 0 in the range. For end node, we exclude
any non-container nodes with offset 0 from the range.
MozReview-Commit-ID: Lt2tCLbapq7
--HG--
extra : rebase_source : 7d86b6cf04581f1cd71fa85f8c8586541b3a84e9
Web standards use "Container" instead of "Parent". So, nsRange shouldn't use "Parent" for its members and methods.
MozReview-Commit-ID: Ho6N0diuWtE
--HG--
extra : rebase_source : ee4eb7068a68b118c7fe98e9e9e7fa9c9e7f13e2
ContentEventHandler::ExpandToClusterBoundary() doesn't check the return value of nsTextFrame::PeekOffsetCharacter(). Therefore, it may set its result to reversed offset. (e.g., when aForward is true and offset is 6, the result may be 5. When aForward is false and offset is 5, the result may be 6.)
For avoiding that, ContentEventHandler::ExpandToClusterBoundary() should check the result and only when it returns nsIFrame::FOUND, it should compute the proper offset.
On the other hand, it's too bad for ContentEventHandler that nsTextFrame::PeekOffsetCharacter() to return nsIFrame::CONTINUE_UNSELECTABLE when the user-select style is "all" because IME doesn't expect such cases.
Therefore, this patch adds additional argument to nsIFrame::PeekOffsetCharacter(), aOptions which is a struct containing bool members. The reason why it's not a bit mask enum is, such struct doesn't cause simple mistake at checking the value and the code is shorter. When mIgnoreUserStyleAll of it is true, this patch makes nsTextFrame not return nsIFrame::CONTINUE_UNSELECTABLE.
MozReview-Commit-ID: ACNNBTP92YZ
--HG--
extra : rebase_source : bd85da902e7fb59135d15514cb20a5599a4a640b
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
nsRange::DoSetRange() adds/remove its root to/from mutation observer, initializes common ancestor, registers itself to the common ancestor, unregisters itself from old common ancestor, and notifies selection listeners of selection change.
However, those runtime cost is expensive but on the other hand, a lot of callers set both start and end of the range and that causes calling DoSetRange() twice.
This patch renames Set() to SetStartAndEnd() for easier to understand the meaning and make it call DoSetRange() only once.
MozReview-Commit-ID: FRV55tuBAgg
--HG--
extra : rebase_source : 67adf929cf119e2425f7d3741651217522094590
This must be a regression of bug 1213589. When removing whole text from an editor, the editor removes moz-<br> after removing all nodes. Immediately before the remove, moz-<br> becomes <br>. So, IMEContentObserver::AttributeChanged() detects the native text length for the <br> element changing from 0 to 2 (on Windows) or 1 (on the other platforms). However, the call of ContentEventHandler::GetFlatTextLengthInRange() in IMEContentObserver::AttributeChanged() returns 2 (on Windows) or 1 (on the other platforms). Although, it tries to get the length from the start of the editor to before aElement, it always includes the length of the line breaker caused by the end node.
The reason is, ContentEventHandler::GetFlatTextLengthInRange() always adds the line breaker's length for the end node without checking the range includes open tag of the end node. Therefore, this patch adds the check into ContentEventHandler::GetFlatTextLengthInRange(). So, ContentEventHandler::GetFlatTextLengthInRange() becomes to support NodePositionBefore() for the end of the range.
Additionally, this patch fixes a bug at appending text node length. In the loop, |aEndPosition| shouldn't be referred because it may be hacked with |endPosition|. So, detecting the last text node should be compared with |endPosition|.
For making the method code safer, this changes whole |aEndPosition| after defining |endPosition| is replaced with |endPosition|.
MozReview-Commit-ID: FUp2nxuQHnO
--HG--
extra : rebase_source : 611992faf95082ce8ae005b7bcce90a3bea4f99e
Currently, ContentEventHandler::OnQueryTextRectArray() is used only in e10s mode (at caching necessary character rects in ContentCacheInChild). Therefore, this bug occurs only in e10s mode.
ContentEventHandler::OnQueryTextRectArray() applies CSS transform only to each frame rect. Therefore, character rect's width and height are not applied.
This patch makes the loop apply CSS transform to each character or line breaker rect (i.e., each item of charRects). Then, we need to rewrite the lastCharRect hack. It stores the last charRect value for computing next line breaker rect if next line breaker is caused by a block level element or something, i.e., not caused by a <br> frame. So, when brRect is computed with lastCharRect, the loop needs to apply CSS transform of the last text frame to the following brRect because it tries to compute a caret rect immediately after the last character. For doing this, this patch adds lastFrame which stores the last frame for lastCharRect and set it to baseFrame. Then, at applying CSS transform to each charRect, it can apply CSS transform of expected frame.
Similarly, when brRect is computed with last text frame, this patch looks for the last text frame from lastTextContent and use it as base frame to apply to CSS transform.
MozReview-Commit-ID: 5Yr2HMrooHd
--HG--
extra : rebase_source : fa643f442036d9167a1df3a4383b0802a1729a3e
JS can create empty text nodes. Therefore, ContentEventHandler::GetLastFrameInRangeForTextRect() shouldn't use it for computing retrieving a text frame (Although, such text nodes shouldn't have primary frames).
MozReview-Commit-ID: EJAthEpNZNU
--HG--
extra : rebase_source : ccd05b46911077daa855a5c085839fd14aadc2ee
nextNodeOfRangeEnd is used for excluding unnecessary node for computing text rect. When aRange ends at start of a text node, the frames which are created for the text node shouldn't be used. However, if the end node of aRange is same as the start node of aRange, the node is not outside of aRange.
This could occur when it's called with empty range or there are some empty text nodes.
MozReview-Commit-ID: C1yCN5WrULe
--HG--
extra : rebase_source : 35d5b8feecd351bef29fe4af79a0f6f5bdad8bec
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
Dorel Luca
Milan Sreckovic
Emilio Cobos Álvarez
Andrea Marchesini
Jessica Jong
Mats Palmgren
Nicholas Nethercote
Cameron McCormack
Nika Layzell
Michael Layzell
Makoto Kato
Masayuki Nakano
Jim Chen
Sylvestre Ledru
Masatoshi Kimura