We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
`nsRange` registers mutation observers to adjust the range when content
changes. However, there are some cases where we adjust the start and/or
end offsets but don't notify selection listeners (i.e. we don't call
`nsRange::DoSetRange` to set the new range points, contrary to what the
comment above `nsRange::DoSetRange` says). This patch makes us call
`nsRange::DoSetRange` in those cases. The patch adds a testcase in
test_selectevents.html, and changes a few unexpected-pass cases in
test_composition_text_querycontent.xul that this patch fixed.
MozReview-Commit-ID: 73D8RYMS3MS
--HG--
extra : rebase_source : da0cc3073e4b8ad23c6f6eab42da5aa8b269cae9
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
This patch adds some automated tests for reproducing bug 1375825 and makes nsQuetyContentEventResult::GetText() work with eQueryTextRect event because ContentEventHandler sets it to the text which was used for computing the rect.
MozReview-Commit-ID: Gk8IV2Vln6V
--HG--
extra : rebase_source : 2d7127c09713358cf9a69fbbc180c325981794b2
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
This patch fixes failures for widget/tests/test_composition_text_querycontent.xul when it is run on ubuntu 16.04. It adds some missing handling for pre-test position change notifications and also adds some handling for after-test position change notifications.
MozReview-Commit-ID: 1t8NuxJqkOo
--HG--
extra : rebase_source : ddae0da39a087c5742e31fbae9d7930b95695f1e
Since committing will do IO on the main thread, it would be better to do it on
an idle thread instead. We have to change JavaScript code too because now the
API is asynchrous.
This patch also updates its xpcshell test.
Now mozilla::widget::AsyncDeleteAllFaviconsFromDisk will get profile directory
on the main thread to prevent it happens on off-main-threads, thus prevents
off-main-thread assertion.
MozReview-Commit-ID: CWcR0B2BC3n
--HG--
extra : rebase_source : 3685a07f9f4476bc94bdf92937734b78fb3fe309
Between nsIDocumentObserver::BeginUpdate() and nsIDocumentObserver::EndUpdate(), IMEContentObserver can cache added nodes as a range if they are consecutive nodes. Even if a node is removed, a data node is changed or attribute is changed unexpectedly, IMEContentObserver can post text change of the added node range and handle it normally.
MozReview-Commit-ID: IttDHBkr92Y
--HG--
extra : rebase_source : f0849d5fab0b28bdfa311cf833a216d43b9215d2
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
Some IME may handle WM_KEYDOWN message before application and may set the keycode value to VK_PROCSSKEY but not do actually. Similarly, IME may handle WM_KEYDOWN message and replace following WM_CHAR messages with different characters.
Therefore, even if WM_KEYDOWN message comes with VK_PROCESSKEY, NativeKey shouldn't stop dispatching keypress events if it detects following printable char messages.
MozReview-Commit-ID: DcC2qgcLDrQ
--HG--
extra : rebase_source : 85c6a5dd5700b4032d1a21ed28b25c313cefa5cd
According to ATOK's behavior, IME may send different line breaker from its platform's standard. Therefore, we should treat \r as \n too.
Additionally, currently, TextComposition doesn't allow to input \n with composition. However, this was added for preventing to see odd control characters as boxes with code point. Therefore, we should allow \n for IMEs. (It was allowed, this limitation is unexpected when I reviewed the patch to reject control characters in TextComposition.)
MozReview-Commit-ID: DzGSMgp89Av
--HG--
extra : rebase_source : 0644e5941a080583af8701546111fbf46ec646ec
Although, TextComposition's bug, those tests are not checked with expected values, we should fix them later.
MozReview-Commit-ID: 89jehNqMnCH
--HG--
extra : rebase_source : 2c622396edef067b92393f1e5e5291db9105417a
Ctrl+Space causes WM_CHAR of ' '. On the other native applications, you can input ' ' with this key combination though, we shouldn't allow this because we need to remove Ctrl and Alt modifier state at dispatching keypress event for the limitation of TextEditor but this is important key combination for custom shortcut keys.
So, when Ctrl or Alt key is pressed but it doesn't change the inputting character, i.e., the character can be inputted without Ctrl or Alt, we shouldn't remove those modifier state from eKeyPress event.
MozReview-Commit-ID: 7omLvNdQWzW
--HG--
extra : rebase_source : 66d5015567799c489d925ac2419358913f808d63
Because of conforming to UI Events KeyboardEvent key Values, when some modifier keys cause not inputting character, the KeyboardEvent.key value should be computed with removing all modifier state except glyph modifier keys.
When Control key is pressed, Cocoa fires odd key events typically. For example, characters isn't computed with same logic of UI Events KeyboardEvent key Values especially when Option key is pressed (see adding testcases for the detail).
Therefore, this patch makes TISInputSourceWrapper::InitKeyEvent() ignore both characters and charactersIgnoringModifiers at computing KeyboardEvent.key value when Control key is pressed and InsertText() isn't called.
On the other hand, this patch does NOT touch the path to compute KeyboardEvent.key when Command key is pressed. It should be changed in different bug because Command key behavior isn't so simple.
MozReview-Commit-ID: dMHgUEOnQw
--HG--
extra : rebase_source : 7a67c98d2bf6ca38c7e6ae9dcbad01020d9cea31
Bug 1137567 - 1. Allow dispatching key events during composition; r=esawin
We potentially dispatch key events during composition to provide
compatibility for pages that only listen to key events.
Bug 1137567 - 2. Allow keyboard events in DispatchInputEvent when not on APZ thread; r=rbarker
We use nsIWidget::DispatchInputEvent to dispatch our keyboard events on
the Gecko thread, which on Android is not the APZ controller thread. We
should allow these events to pass instead of crashing.
Bug 1137567 - 3. Add GeckoEditableSupport class to support TextEventDispatcher; r=masayuki
Add a separate GeckoEditableSupport class, which implements
TextEventDispatcherListener and uses TextEventDispatcher for IME
operations. The new class is entirely separate from nsWindow to allow it
to be independently used in content processes as well.
Most of the code is copied from nsWindow::GeckoViewSupport, and adapted
to use TextEventDispatcher.
Bug 1137567 - 4. Make nsWindow::WindowPtr available for outside classes; r=snorp
Make nsWindow::WindowPtr available not just for classes inside nsWindow
but for outside classes as well. Also, add support for RefPtr native
objects to nsWindow::NativePtr.
Bug 1137567 - 5. Use GeckoEditableSupport in nsWindow; r=esawin
Use the new GeckoEditableSupport class in nsWindow to replace the
previous code in nsWindow::GeckoViewSupport. GeckoEditable native
methods now go to GeckoEditableSupport instead of GeckoViewSupport.
Several native methods in GeckoEditable are changed from
dispatchTo="proxy" to dispatchTo="gecko", because we no longer need the
special nsWindow::WindowEvent wrapper for our native calls.
Bug 1137567 - 6. Use pushPrefEnv in test_assign_event_data.html; r=masayuki
setAndObserveCompositionPref in test_assign_event_data.html does not
invoke the callback if the pref is already set. This patch changes it to
use SpecialPowers.pushPrefEnv so the callback is always invoked.
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
Bug 1319660 - 1. Don't take shortcut if old replacement ranges don't match; r=esawin
The block at [1] is a shortcut we take when we reconcile Java text
changes with Gecko text changes. However, we only checked that the new
ranges are the same, i.e. that the new Gecko text is the same as the new
Java text. We should also be checking that the old ranges are the same,
i.e. that the replaced Gecko text is the same as the replaced Java text.
[1] https://dxr.mozilla.org/mozilla-central/rev/bbbd2f7539f224a482cc6d2dd10e6a5f31c8baf3/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoEditable.java#1233
Bug 1319660 - 2. Use previous node instead of sibling when adjusting last node; r=masayuki r=smaug
nsContentIterator in pre mode adjusts its last node if the node is a
childless node like <br>. However, right now it's using GetPrevSibling,
which can lead to error in some edge cases such as:
<p></p><div><br></div>
In this case, if the last node is <br> with offset 0, GetPrevSibling
will return <p> because <p> is <br>'s parent's previous sibling, and the
last node will be set to <p>. However, the correct last node in this
case is <div>, because <br> with offset 0 refers to the position to the
left of <br>, which is <div> with offset 0. In this case, PrevNode
returns the correct <div> value, so we should set the last node to the
result of PrevNode.
For the first node, for a childless node in pre mode, GetNextSibling and
NextNode are the same, so there is no bug in this case. Nevertheless,
this patch changes the call to NextNode to be consistent with calling
PrevNode for the last node.
Bug 1319660 - 3. Add test for correctly adjusting last node in content iterator; r=masayuki
Add a test for the previous patch that makes sure querying selected text
in an edge case works correctly.
Bug 1319660 - 4. Add test for start node regression; r=me
Add a new test case for the NextNode() regression. r=me for trivial
test-only patch.
Bug 1319660 - 5. Restore GetNextSibling call for first node of pre-content-iterator; r=smaug
The last patch changed the `GetNextSibling()` call to `NextNode()`
because I assumed they're equivalent in this case. That turned out to
not be the case because we can reach this line even if the node has
children -- the index just has to be after the last child. So this patch
restores the `GetNextSibling` call to restore the correct behavior.
I also added some comment to clarify that we can reach this line due to
one of two conditions: 1) the node has no children; 2) the node has
children but the index is after the last child.
This patch also replaces the `HasChildren()` check when setting
`cChild`. If the index is after the last child (i.e. index ==
childCount), `GetChildAt()` fails and we erroneously log an assertion
warning, even though the input was valid. The new check handles all
cases whether start node has children or not.
Eric Rahm
Nicholas Nethercote
Yoshi Huang
Stone Shih
Carsten "Tomcat" Book
Christoph Kerschbaumer
Masatoshi Kimura
Jim Chen
Masayuki Nakano
Greg Mierzwinski
Wei-Cheng Pan
Florian Queze
Sebastian Hengst
Joel Maher
Dan Banner
Andreas Farre
Wes Kocher
Gijs Kruitbosch
Tooru Fujisawa
Mark Banner
Ryan VanderMeulen