This is important for RTL locales which are drawn with explicit direction but
measured with no direction.
MozReview-Commit-ID: C4k5vgpKggD
--HG--
extra : rebase_source : 6fc3c6dae296d8dabe189361481b12a17e75dcc6
Previously oldState differed from aStateFlags just because it contained
direction flags.
MozReview-Commit-ID: DuGpHdt9EuX
--HG--
extra : rebase_source : 05a06d130a51c7a1830804254ec87c6697ade4a8
Currently, NativeKey::DispatchPluginEventsAndDiscardsCharMessages() calls nsWindowBase::DispatchPluginEvent() and nsWindowBase::DispatchPluginEvent() does nothing when windowless plugin doesn't have focus. However, this is unclear when other developers read the code of DispatchPluginEventsAndDiscardsCharMessages() and it causes unnecessary virtual calls. So, it should try to dispatch plugin events only when a windowless plugin has focus.
For making the check safer, nsWindowBase should expose the method to check it as ShouldDispatchPluginEvent(). Unfortunately, we cannot mark this method as const due to PluginHasFocus() needs to be not const method, though. Then, for loops in DispatchPluginEventsAndDiscardsCharMessages() should check it at each try.
This change helps to log the behavior (working on bug 1297013) without noise.
Additionally, this patch renames the method to MaybeDispatchPluginEventsForRemovedCharMessages() because it doesn't remove any char messages anymore.
MozReview-Commit-ID: F14Lcx47M6U
--HG--
extra : rebase_source : 64b6da75590c99299f75358023844762198136d6
NativeKey removes odd WM_CHAR messages which are caused by ATOK or WXG if the user tries to do "Kakutei-Undo" (meaning "undo the last commit") after dispatching eKeyDown event.
However, NativeKey should remove them from the queue first because there are some problems:
* If focus is moved during dispatching an eKeyDown event, we'll fail to remove the messages from the queue.
* If dispatching eKeyDown advance native event loop due to entering to a modal loop or dosing synchronous XHR, the message pattern is broken before removing the odd messages from the queue.
After removing the odd char messages, NativeKey should store them with mRemovedOddCharMsgs because NativeKey needs to dispatch them to focused windowless plugin.
Note that this patch also fixes a bug of the loop to remove the odd WM_CHAR messages. Old code removes only one WM_CHAR messages, but we need to remove all WM_CHAR messages before WM_KEYUP. This must be a regression.
MozReview-Commit-ID: I60bcIx2SFS
--HG--
extra : rebase_source : 19d0e70d9f39e6d0476c62def5e0a2dc1e0ab444
NativeKey is now removing and storing following char messages when it's created for a keydown message. Therefore, IsFollowedByNonControlCharMessage() just refers the stored messages and it's enough fast. So, we can get rid of mIsFollowedByNonControlCharMessage.
MozReview-Commit-ID: 542A2sHNXeC
--HG--
extra : rebase_source : e748c9855c3cf2d45609f94f9ccc8d43d29dc447
GetFollowingCharMessage() is now called only when removing following char message. Therefore, it does not need to have the optional argument indicating if removing the found message.
MozReview-Commit-ID: 7P39wyfSC1
--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2
While dispatching an event, focused widget may be changed. In such case, NativeKey shouldn't continue to dispatch remaining events (eKeyPress events) for preventing to dispatch to input text in unexpected website.
MozReview-Commit-ID: 7geuqks0LQK
--HG--
extra : rebase_source : 3e6c82e1eb0e27115fe93b1a3b4a155914fd06f7
In some cases, we may receive following char message of WM_*KEYDOWN *during* dispatching an eKeyDown event. In such case, NativeKey shouldn't dispatch eKeyPress event twice (one is caused by receiving WM_*CHAR message, the other is caused by post dispatching eKeyDown event code).
This patch makes NativeKey consume following WM_*CHAR messages before dispatching eKeyDown. Therefore, the former case will never occur.
For doing that, NativeKey stores following WM_*CHAR messages in mFollowingCharMsgs and uses it when it needs to dispatch eKeyPress events for each WM_*CHAR message.
MozReview-Commit-ID: 6QNvlwVVlTz
--HG--
extra : rebase_source : c33b5a1ac503326d51ef78f4f8a09c9a63df7871
You know, when Korean IME commits string, then it sometimes set next preedit string. So reseting context causes that next preedit string is committed.
So we shouldn't reset IME context with preedit_end.
MozReview-Commit-ID: CZJJvYjcrKY
--HG--
extra : rebase_source : d7e2e80930355794a40466c68fe22e43e7164d72
For safety, NativeKey::GetScanCodeWithExtendedFlag() returns without extended flag on WinXP and WinServer2003 because ::MapVirtualKeyEx() API doesn't support extend key conversion.
However, extended scan code is available even on them when lParam has 0x1000000 especially when it computes KeyboardEvent.code value. Therefore, it should return with 0xE000 for extended keys on any versions of Windows.
Note that NativeKey::ComputeVirtualKeyCodeFromScanCodeEx() wraps ::MapVirtualKeyEx() API. It checks if the API is not available for the result of NativeKey::GetScanCodeWithExtendedFlag(). So, returning extended scan code from NativeKey::GetScanCodeWithExtendedFlag() is safe.
MozReview-Commit-ID: D2RrHxPI9ET
--HG--
extra : rebase_source : 51f277e8331eb7ad109c3227ac1fe73f6de48105
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 197b249740056e5c4b7c6f3b556f91f50a838d52
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
Separate compiled JARs into GECKOVIEW_JARS and FENNEC_JARS, and run
AnnotationProcessor separately on each set. The GeckoView bindings are
put into widget/android/GeneratedJNI* (same as before), while the
Fennec-specific bindings are put into widget/android/fennec/FennecJNI*.
ibus-pinyin has a bug. When application calls gtk_im_context_reset(), which means selection is changed in application, ibus-pinyin sents a set of composition signals with empty commit string. Therefore, selecting text causes removing it.
For preventing it but not breaking the other IMEs which use surrounding text, we should give up to call gtk_im_context_reset() if IME hasn't retrieved surrounding text after the last selection change. Not having retrieved surrounding text means that the IME doesn't have any cache of contents. Therefore, not calling gtk_im_context_reset() at selection change must be safe for such IMEs.
MozReview-Commit-ID: 5cbIZjpd7zN
--HG--
extra : rebase_source : 6010b3e055d66ebd2ed50f9b3ee8ff2330d3c6ab
This patch includes a small memory optimization of using ArrayList and
`volatile int` for storing the pending thumbnails list and pending
width, instead of using LinkedList and AtomicInteger, respectively.
The patch also fixes a possible race condition due to calling
processNextThumbnail outside of a lock. Now it must be called inside a
lock and its name is changed to reflect that.
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 37f78552a1ebba6f61c38add0138b84ddef36c3e
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 0f4bb9193aa06cd7985590636b77a6e2a71ac2e4
Previous design is only to request audio focus for audible media, but now we
also request focus for non-audible media.
It's simple that the app should own the focus when users start watching media.
MozReview-Commit-ID: 3eJP26h4kh7
--HG--
extra : rebase_source : b35c4ef7d6560635f428eba445f089abd3844bda
eQueryTextRect is used by widget and eQueryTextRectArray is used by ContentCacheInChild. So, matching their result guarantees that widget can get same result both in non-e10s mode and e10s mode. So, the matching should be tested.
MozReview-Commit-ID: 6GfbyvZ9X7H
--HG--
extra : rebase_source : 12511d84cbd94b3f4edf42367a84ee45abc66d9e
Ctrl+Backspace causes WM_CHAR for control character DELETE. However, NativeKey::IsControlChar() doesn't treat it as a control character. Therefore, NativeKey treats Backspace key as a printable character.
MozReview-Commit-ID: 29V45CNp8kW
--HG--
extra : rebase_source : 6656d884addf8b49dfa7c12d0b2c8d0543493c4f
On some keyboard layouts, a key sequence, a dead key -> another dead key, may produce a composite character instead of two base characters for each key. For example, with "Russian - Mnemonic" keyboard layout on Win 8 or later, both 's' and 'c' are dead keys but key sequence, 's' -> 'c', produces a Unicode character.
For solving this issue, this patch fixes 2 bugs:
First, KeyboardLayout::GetDeadKeyCombinations() doesn't add dead key entry if 2nd key is a dead key (::ToUnicodeEx() returns -1). In such case, it should add a dead key entry with the first character which is produced when only the 2nd key is pressed (the character is called as "base character" and used for index of the dead key table).
Next, KeyboardLayout::InitNativeKey() should check if 2nd dead key press produces a composite character. If it's produced, it should initialize given NativeKey with the composite character. Otherwise, it should initialize with base characters of each key. This patch does it with KeyboardLayout::MaybeInitNativeKeyWithCompositeChar().
Finally, we should add automated test for this. However, unfortunately, it's not available on Win7 and our infra is still using Win7 for running automated tests. Therefore, this patch doesn't include new automated tests.
MozReview-Commit-ID: G1DrfkHKNcK
--HG--
extra : rebase_source : 6ff4278d594a26a0908464b1e603a0a7ee2b3b38
It's difficult to understand what data is created by KeyboardLayout::LoadLayout(). So, for understanding what data is created, let's add logging code into it.
MozReview-Commit-ID: CelxyVpGn5f
--HG--
extra : rebase_source : fd8f15a42c4c2b4c1f1079184060c6e5f796ac5a
Based on crash reports, and issue was fixed in later drivers.
Also blocking 15.x up to 15.301.2301.1002.
MozReview-Commit-ID: F4kJta8JH1K
--HG--
extra : rebase_source : 5f69443b72cfefde052f70e27d8cf98128b3b913
There are 2 bugs and this patch fixes them once.
First, NativeKey::WillDispatchKeyboardEvent() is used to setting alternative charCode values for every eKeyPress event. However, for supporting "reserved" shortcut keys, now, it sets alternative charCode values to eKeyDown too. However, they are really different. eKeyPress events are fired for every character to be inputted by a key press sequence. On the other hand, eKeyDown event is fired only once for a key sequence. Therefore, now, NativeKey::WillDispatchKeyboardEvent() needs to set alternative charCode values for all characters inputted by the key sequence to eKeyDown event.
The other is not a new bug. NativeKey::WillDispatchKeyboardEvent() sets the last eKeyPress event's special alternative charCode values, such as unshifted Latin character, shifted Latin character and some character which can be computed from virtual keycode. This is performed when given index is the last index of the longest input string of the key. However, the value includes different shift key state. I.e., when different shift key causes longer text input, NativeKey::WillDispatchKeyboardEvent() won't set the special alternative charCode values to any eKeyPress events. For example, when Ctrl+T is pressed with Arabic keyboard layout, its unshifted input string length is 1 but shifted input string length is 2. Then, eKeyPress event is fired only once, but NativeKey::WillDispatchKeyboardEvent() waits second eKeyPress event.
Therefore, this patch makes the method append alternative charCodes for all remaining characters and detect the last event correctly with mCommittedCharsAndModifiers (it's used for KeyboardEvent.key value of eKeyDown event and the count of eKeyPress events is same as the value's length).
MozReview-Commit-ID: 6adUnmi5KYy
--HG--
extra : rebase_source : 8c04a3a155f2fcb9a5a8b3e9e0a176c678dc6265
When investigating bug 1075194, I found that we don't check return value of DocumentPropertiesW. So we sould use correct type and add log for this API.
MozReview-Commit-ID: Ck3VwMq9OpQ
--HG--
extra : amend_source : a0da15b578055b7612ce96b44cac2cd69607fa51
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
Some tests in test_keycodes.xul emulate native key event with printable character even when Ctrl or Alt key is pressed.
With en-US keyboard layout, Ctrl+[A-Z] causes a control character's WM_CHAR message. However, the other OEM keys and numeric keys don't cause WM_CHAR message when Ctrl is pressed. So, we need to fix some wrong emulations in it now.
MozReview-Commit-ID: bhF5XeClnd
--HG--
extra : rebase_source : 16b7c1e725cf8877b2b44f8d7f52e129889ed25f
The new test failure is caused by a bug of the test API, KeyboardLayout::SysnthesizeNativeKeyEvent(). It doesn't generate WM_SYSKEY* messages nor WM_SYS*CHAR messages when Alt key is pressed. Therefore, the new path in the previous code works unexpectedly with automated tests.
This patch makes KeyboardLayout::SysnthesizeNativeKeyEvent() WM_SYS* message aware. When Alt key is pressed (but Ctrl key is not pressed) and the Alt key + something doesn't cause text input, the API generates WM_SYS* messages as expected.
MozReview-Commit-ID: FLbe4SYEZLf
--HG--
extra : rebase_source : 054147997eddfb01dbad63afc07e0b4f59a60257
Some keyboard utilities for Windows can change non-printable keys to printable keys. Therefore, if a keydown message is followed by one or more char message whose wParam isn't a control character, NativeKey should treat it as a printable key's event.
MozReview-Commit-ID: HoFbz5Zafeh
--HG--
extra : rebase_source : 9001c58cb082a93946e1b4c445dfe71f15d08997
Since TestWinTSF.cpp isn't available for long time, we should remove it.
Although, we need to create automated tests for native IME handlers, but we should do it in another bug and new frame works should be writable by JS for easier to write tests.
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : f276e1629fcd0ffccb8c8dbec7bba6639a5ebd9f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : b8a0d9a49b31929dd06af9e61fc57f484af7671d
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
Make the GeckoAppShell.cameraCallbackBridge callback use the new native
JNI bindings. Also refactor the relevant code in GeckoAppShell and
CameraStreamImpl.
Get rid of LayerView.Compositor.getSurface and just pass in the surface
when creating or resuming the compositor. That also lets us get rid of
some synchronization required for getSurface.
Now that nsWindow doesn't own LayerViewSupport, we shouldn't be using
WindowEvent for LayerViewSupport calls. This patch converts the calls
that dispatch to proxy to dispatch directly to Gecko. For
SyncResumeResizeCompositor, it used a proxy to call OnResumedCompositor
on the Gecko thread; this patch makes SyncResumeResizeCompositor post an
event to call OnResumedCompositor directly, without going through the
proxy.
Right now we report Java exception stacks through two code paths:
- GeckoAppShell.reportJavaCrash for exceptions caught by Java code
- jni::HandleUncaughtException for exceptions caught by native code
This patch combines the code for reporting the Java stack trace into
ReportException, to make it easier to add new features such as reporting
OOM exceptions.
We used to only handle certain exceptions in native code, and otherwise
forward the exception to Java handling code. Handling exceptions in
native code gives us better native stack traces in crash reports, so
this patch makes us always handle uncaught Java exceptions in native
code if possible, and only forward to Java as a fallback.
KeyboardEvent::InitNativeKey() should initialize NativeKey if it's created for handling an orphan WM_CHAR message, however, if it the charCode isn't a printable character such as 0x0D for Enter key, it shouldn't refer it because focused editor shouldn't handle keyboard event as inputting the non-printable character.
MozReview-Commit-ID: FwTdGqhPEld
--HG--
extra : rebase_source : 69da91ad47e64199c8ff6c120522eb7e153122cd
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Make the generated SDK binding files depend on the annotation processor
jar file, so that changes in the annotation processor will cause the
bindings to regenerate.
We need to set the compositor-created flag in LayerView correctly when
reattaching to a new LayerView, so that we resume the compositor instead
of trying to create the compositor again, which we already did
previously.
This patch consists of general code cleanup and a new reattach method in
LayerView.Compositor that we call in order to set the compositor-created
flag correctly.
Its return value is only checked in one low-value assertion.
The patch also does the following.
- Removes the Android and GTK overloadings of EnableDragDrop(), which are
identical to the nsBaseWidget one.
- Streamlines the Windows implementation: fixes the indentation and takes
advantage of infallible |new|.
--HG--
extra : rebase_source : d090848cf5ea2e92c0188b07559c1e1f3899829f
Start offset of composition string is fixed when composition string becomes non-empty in focused editor. In other words, until composition string is fixed, composition start offset may be changed from selection start offset at dispatching compositionstart event. Especially, in e10s mode, pending keyboard events usually change composition start offset.
So, while there is composition, IMEHandler should use query events querying text rect or text content relative to actual start offset of composition string because native IME believes composition string at selection selection start when starting composition in the main process.
MozReview-Commit-ID: 3hinwozl9Ow
--HG--
extra : rebase_source : 4b79dd4f53aa51edfc78ff08c07a710160a8de01
The only implementation of SetSizeMode() that can fail is the nsCocoaWindow
one, on an Objective C exception, which is unlikely and can be swallowed.
This allows some nsGlobalWindow functions to become infallible as well.
--HG--
extra : rebase_source : 85d54185f63d2c138ee3f3e0e0bfe3b5e805a981
Returing TS_E_NOLAYOUT while ATOK shows suggest window causes moving suggest window to odd position. This causes flicking the window. Therefore, we shouldn't return TS_E_NOLAYOUT in this case. In this case, ATOK queries whole rect of composition string. So, we can return TS_E_NOLAYOUT for other cases.
MozReview-Commit-ID: LBZQPFjqQgx
--HG--
extra : rebase_source : 27fda6739562dfaf89efd1d2cd9cac03610846ba
ContentCache::TextRectArray::GetUnionRectAsFarAsPossible() should avoid crash by itself even if it's caller's bug. This makes parent process more stable, that is what one of the purpose of e10s is.
MozReview-Commit-ID: qKAfvm6eZw
ContentCache::TextRectArray's end offset is computed as start offset + its length. Therefore, end offset is the last offset in the range + 1. So, IsOverlappingWith() shouldn't return true only when end offset is overlapped with given range.
That means that when TextRectArray doesn't have rects, i.e., mRects is empty, IsOverlappingWith() always returns false. And when TextRectArray has one or more rects, IsOverlappingWith() should compare its range and given range without "=".
MozReview-Commit-ID: JxNPcEwikjR
They don't need to be NS_IMETHOD, but they should be MOZ_MUST_USE. Adding the
latter catches a few missing checks, which the patch adds.
The patch also gives PuppetWidget an InfallibleCreate() function, which makes
the infallibility of PuppetWidget creation clear.
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
ATOK 2011 - 2016 check focused window class name if it's a Mozilla's window. Then, they refer native caret position for deciding its popup window. However, future ATOK release will stop referring native caret position on Mozilla's windows. Therefore, we can stop creating native caret for new ATOK.
MozReview-Commit-ID: HPh3DVqTkvc
--HG--
extra : rebase_source : 00b75b75df2ba1bace328cfb75172c78c6bea29d
ContentEventHandler and ContentCache allow 0 length text rect query. However, if selection is collapsed and caret is at the queried offset, they return actual caret rect whose height (in horizontal layout, width in vertical layout) may be different from actual font height of the line.
Therefore, it may cause "dancing" of candidate or suggest window of TIP. Therefore, we should query text rect at least 1 length. Then, even if there is no character at the offset, they computes caret rect with previous character.
MozReview-Commit-ID: 9LprWTPyMsF
--HG--
extra : rebase_source : c0dfad35bcc1961948e21c8b50b21cdf218ba966
When TSFTextStore::GetTextExt() needs to hack the queried range, it means that the method should not return TS_E_NOLAYOUT since the hacks are implemented for that. However, currently, if hacked offset is still at modified offset, it returns TS_E_NOLAYOUT. This causes flicking IME windows.
For avoiding that, this patch adjust the hacked offset to the last unmodified offset or offset of the start of composition string. Even if there is no modified character in the composition string, we can use the offset since even if there is no character at the offset, query content event returns caret rect at the offset and if there are old characters, it returns its rect which the user still see. So, the rect at the composition start is useful until layout is modified actually.
MozReview-Commit-ID: 4zo9mF3m9u9
--HG--
extra : rebase_source : 6dd15b62422b85edf04150f15caaca45d7bc3600
Currently, TSFTextStore::GetTextExt() checks the offset with mContentForTSF.MinOffsetOfLayoutChanged() as "the first offset of modified characters", however, TSFTextStore::Content::IsLayoutChangedAfter() needs actual offset - 1. This is really not useful. So, we should rename it to IsLayoutChangedAt() and check the offset simply.
Additonally, TSFTextStore::GetTextExt() should set previous offset of MinOffsetOfLayoutChanged() when it hacks the queried range for avoiding bug of active TIP since setting offsets to the result of MinOffsetOfLayoutChanged() means the offset's layout is always not computed yet.
MozReview-Commit-ID: 182BMuubtFc
--HG--
extra : rebase_source : 65355fc4e488592f59dfc0b44806571ff0b87cd6
It's possible for LayerView to be destroyed before it's finished
initializing on the Gecko thread. In that case, we should not continue
with normal destruction of NPZC. Checking isGeckoReady() in
GeckoLayerClient accomplishes that. Also, guard against a case where
LayerView.onSizeChanged is called after LayerView destruction and
results in a NPE from mCompositor being null.
This patch makes the following changes on many in-class methods.
- NS_METHOD F() override; --> NS_IMETHOD F() override;
- NS_METHOD F() override {...} --> NS_IMETHOD F() override {...}
- NS_METHOD F() final; --> NS_IMETHOD F() final;
- NS_METHOD F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 3010fade82a170eab7f13d81bf61b02cd693f3cf
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
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 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
All these occurrences are for methods declared with NS_IMETHOD, and so they
should be NS_IMETHODIMP instead of NS_METHOD.
--HG--
extra : rebase_source : 50b0c0f46cab6a13cc27ad48fb24503b9a491463
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
NS_OBJC_{BEGIN,END}_TRY_LOGONLY_BLOCK{,RETURN} are identical to
NS_OBJC_{BEGIN,END}_TRY_ABORT_BLOCK{,RETURN}. This patch removes the LOGONLY
versions in favour of the ABORT versions.
--HG--
extra : rebase_source : 4537de8986b87784d2a80ead24999310adbdece8
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
Combine the callObserver and removeObserver methods used for notifying
alert listeners into the native method
GeckoAppShell.notifyAlertListener. Keep track of the listener and the
alert cookie on the native side so that we don't need
GeckoAppShell.ALERT_COOKIES anymore.
Refactor the notification-related methods in GeckoAppShell. In
particular, combine showPersistentAlertNotification into
showAlertNotification, and move code out of AndroidBridge.
Add native method calls to AndroidGamepadManager to replace the gamepad
events in GeckoEvent. Implement those calls in AndroidGamepad.cpp. The
jni/Refs.h change is necessary to fix a compile error when using
jni::BooleanArray.
Add a native method in ZoomedView to request zoomed view data. The
native method is implemented in the ThumbnailHelper class on the C++
side because it shares a lot of code with the thumbnailing code.
Carsten "Tomcat" Book
David Anderson
Thomas Wisniewski
Tanuja Sawant
Bill McCloskey
Karl Tomlinson
Andrew Comminos
Masayuki Nakano
Makoto Kato
Xidorn Quan
Wes Kocher
Jim Chen
Nicolas Silva
Alexandre Lissy
Nathan Froyd
Kartikaya Gupta
Phil Ringnalda
Mason Chang
Gerald Squelart
Alastor Wu
Shing Lyu
Manish Goregaokar
Stephen A Pohl
Aaron Klotz
Jonathan Kew
Michael Layzell
Ryan VanderMeulen
Markus Stange
Martin Stransky
Ho-Pang Hsu
Chih-Yi Leu
Sebastian Hengst
Ryan Hunt
Lee Salzman
Botond Ballo
Ou Shinjo
Nicholas Nethercote
Ethan Lin
Michelangelo De Simone
Milan Sreckovic
Randall Barker
Stone Shih
Aryeh Gregor
Olli Pettay
Kan-Ru Chen
Sotaro Ikeda
Chris Peterson
Jeff Gilbert
John Lin
Igor
eyim
Jimmy Wang
Ben Tian
Benjamin Neff
Daniel Glazman
Yura Zenevich