This patch adds following Microsoft's IMEs into the black list which set
their open state to "closed" when input scope is set to IS_URL and sets
input scope for the URL bar to IS_DEFAULT.
Additionally, this adds a new pref to disable this hack because a lot of
users will affect this hack but perhaps, somebody may not like this if
they use tablet.
The new black listed IMEs:
- Microsoft Bopomofo
- Microsoft ChangJie
- Microsoft Phonetic
- Microsoft Quick
- Microsoft New ChangJie
- Microsoft New Phonetic
- Microsoft New Quick
- Microsoft Pinyin
- Microsoft Pinyin New Experience Input Style
- Microsoft Wubi
- Microsoft IME for Korean (except on Win7)
- Microsoft Old Hangul
MozReview-Commit-ID: BwJKFcu80B8
The functions changed are given signed arguments (that are converted to unsigned).
Changing them to signed resolves the warnings and preserves the original values.
MozReview-Commit-ID: BxIAECFiuQR
When "mozAwesomebar" is set to inputmode value, that means that the Smart
Location Bar gets focus. In that case, we should notify IME of input scopes
as "URL" because on-screen keyboard for URL has some useful additional keys
but they are not hindrances even when users want to type non-URL text.
On the other hand, MS-IME for Japanese and Google Japanese Input changes their
open state to "closed" if we notify them of URL input scope. A lot of users
complain about this behavior. Therefore, we should notify only them of
"Default" input scope even when "mozAwesomebar" has focus.
MozReview-Commit-ID: DIgqpR7TXQx
This warning is saying the operation may be undefined because the value of
->left is not guarenteed to be the same because of undefined order of operations.
Fortunately, this seems like a typo and we actually meant to assign ->bottom
MozReview-Commit-ID: H5G8fnDwIJP
Currently, TSFTextStore::GetIMENotificationRequests() tries to return notification requests for focused text store. However, if there is sEnabledTextStore, all notifications will be sent for it. Therefore, TSFTextStore::GetIMENotificationRequests() should return notifications for sEnabledTextStore without checking focused text store in the thread manager.
For example, we try to keep active composition even if we're being inactivated because Windows steals focus from us when our main process becomes busy but user may want to continue to compose the composition after our process becomes available.
Additionally, if TSFTextStore::GetIMENotificationRequests() doesn't return IMENotificationRequests::NOTIFY_DURING_DEACTIVE, sEnabledTextStore will be broken by NOTIFY_IME_OF_BLUR which will be sent by IMEStateManager::OnChangeFocusInternal(). However, when we're being activated, NOTIFY_IME_OF_FOCUS won't be notified because focused remote process keeps having IMEContentObserver. Therefore, sEnabledTextStore won't be recreated and IME becomes unavailable.
Therefore, while sEnabledTextStore is not nullptr, TSFTextStore::GetIMENotificationRequests() needs all notifications even if it loses focus in the thread manager.
MozReview-Commit-ID: CC6gJIpHxUO
This is remaining cases of bug 1312302. TSF may set focus to context when it receives focus related message. In such case, TSF tries to retrieve selection but TSFTextStore::GetSelection() returns E_FAIL due to still not initialized, TSF crashes.
This patch moves the hack to TSFTextStore::GetSelection() and restrict to work only on problematic versions of Windows 10.
MozReview-Commit-ID: 6cTiZ4HCO18
TSFTextStore::GetIMEOpenState() may be called a lot. Therefore, TSFTextStore should cache the compartment until shutting down.
MozReview-Commit-ID: 2jz8zQMBHRS
sMessagePump is necessary only when WinUtils::(Get|Peek)Message() retrieves a message from the queue. Therefore, we can put off to initialize it until then.
MozReview-Commit-ID: ByMJk6AIw1r
sKeystrokeMgr is required only when WM_KEYDOWN or WM_KEYUP message are received. So, we can put off to initialize sKeystrokeMgr until then.
MozReview-Commit-ID: JsLeM0SYXG6
TIP name may be localed on some locales of Windows. Additionally, names may be updated in the future releases. So, it's safer to use GUID rather than name when TSFStaticSink checks active TIP is a specific one.
MozReview-Commit-ID: 6HNePZV7kgJ
Easy Changjei, a Traditional Chinese IME, isn't available on Firefox because:
* The vendor has gone and nobody keeps maintaining it.
* It crashes at first key press since it was built with older Visual Studio and depends on the version's CRT.
Therefore, we don't need to support it anymore.
MozReview-Commit-ID: LjyAvWsrlJ1
Getting all prefs for TSFTextStore during initializing may make damage to start up performance.
So, each one should be retrieved when the one is actually necessary.
This patch creates TSFPrefs (I like better to name it TSFPreferences, but such long name isn't better when calling long name methods.) and implemented by simple macro.
MozReview-Commit-ID: A01LEAW4E7i
ITfProcessorProfiles are used by a debug method TSFTextStore::CurrentKeyboardLayoutHasIME() and TSFStaticSink (when it's initialized). However, TSFStaticSink isn't necessary until when TSFTextStore needs to hack something for specific IME or notifying IMEHandler of active TIP change. So, we can put off to create the instance of ITfInputProcessorProfiles and TSFStaticSink.
MozReview-Commit-ID: KcrqUbqz1do
TIPs (and normal keyboard layouts) don't need IMC on focused window. So, in most environment, it's not necessary to restore default IMC of focused window.
Therefore, this patch makes IMEHandler not restore default IMC unless legacy IMM-IME is active and disassociate IMC from focused window when IMM-IME isn't active.
However, this is risky change. Therefore, the new behavior is disabled in default settings. On the other hand, we need the new behavior only when MS-IME for Japanese is active on Win10. Therefore, this patch adds a pref to enable/disable the hack and make it true in the default settings.
MozReview-Commit-ID: KAVxVT9CrsW
While initializing or destroying TSFTextStore, each object methods should be
called after the instance is grabbed by local variable since member variable
may be cleared by nested call to destroy a TSFTextStore instance.
MozReview-Commit-ID: CojLasqcDyB
On Windows, when nsWindow is created, IMEHandler::InitInputContext() is called. Then, it calls TSFTextStore::SetInputContext(). However, at least for now, TSFTextStore needs to do nothing until the widget gets focus.
MozReview-Commit-ID: HBafHEUSCtd
I did my best to remove as much stuff as possible in this patch. The starting
point was to remove all the IsVistaOrLater() and IsWin7OrLater() calls, but I
also grepped for various strings and found some other removable stuff that way.
I may have still missed some things.
Notable things done by this patch.
- It removes numerous blocklist entries.
- It removes CanComputeVirtualKeyCodeFromScanCode(), because it's always true
now.
- It removes ShowXP{Folder,File}Picker(), even though these were available as
fallbacks on Vista+. The "when platform is built without the longhorn SDK"
condition in the comment above nsFilePicker::ShowXPFolderPicker() sounds like
it won't ever happen any more.
- It removes the config.trim_on_minimize preference. This requires adding a
bool sHaveInitializedPrefs variable; previously the lack of pref
initialization was indicated by the tri-state sTrimOnMinimize variable having
the value 2.
Notable things *not* done by this patch.
- ClearThemeRegion() still exists. The comment suggests that it is XP/Vista
only, but the code suggests otherwise. jimm thinks the comment is wrong.
- The comment in WinWakeLockListener::Callback() suggests that the StartTimer()
call is no longer needed to block the screen saver. I'm uncertain about this
and so I think it's best left to a follow-up.
When PC supports table mode, TextInputFramme.dll is loaded and it can be used for TIP.
When creating new TextStore object, selection might be nothing yet on e10s. At this time, GetSelection will return E_FAIL since selection data isn't received yet. If GetSelection returns error during SetFocus, TextInputFrame.dll will crash.
So we set temporary selection to avoid crash.
MozReview-Commit-ID: HyVSwvhXGJh
TSFTextStore shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: Iu8IWwEOxaf
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
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
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
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
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
In CreateAndSetFocus(), SetInputScope() is called *after* setting focus to the context. At this time, Google Japanese Input retrieves InputScopes. Therefore, TSFTextStore returns IS_DEFAULT. But after that, Google Japanese Input tries to retrieve InputScopes after every notification (in this case, a call of ITextStoreACPSink::OnLayoutChange()). Then, we return IS_URL due to set after returns IS_DEFAULT.
This is actually our fault, but according to the other TIPs, Google Japanese Input shouldn't commit composition at detecting an InputScope change, though.
MozReview-Commit-ID: 2tPlcEA0MI0
I'm still not sure what we should do in this case, though.
If mContentForTSF is initialized and there are some unknown changes in actual contents, i.e., not caused by composition of the active TIP itself, we cannot set selection range properly in some cases.
For example, if TSF tires to set non-empty selection range but the range has been removed by web apps.
For now, let's try to return E_FAIL in such case because that should occur at reconversion or something immediately after previous content change not caused by previous composition. If TIP does nothing in this case, user can retry with same operation after all pending text changes are notified to TSF.
MozReview-Commit-ID: 9unrNVeC1tW
Same as selection change notification, text change notification shouldn't be notified to TSF while there is cachec content because neither TSF nor TIP may allow to change text by web applications during keeping storing cached content.
This patch makes TSFTextStore stores and merges text changes until MaybeFlushPendingNotifications() is called and there is no cached content.
MozReview-Commit-ID: 9fj0GREbX18
TSFTextStore shouldn't notify TSF of selection change until MaybeFlushPendingNotifications() is called and there is no cached content because while there is cached content, neither TSF nor TIP may allow to change selection by web applications. Therefore, ITextStoreACP::GetSelection() and similar methods need to use mSelection instead of actual selection in the focused editor. Therefore, TSFTextStore should store selection change data during keeping storing content cache and notify it when the cache is cleared. So, when TSFTextStore notifies TSF of selection change, TSFTextStore needs to update mSelection to the actual selection which is stored in mPendingSelectionChangeData.
MozReview-Commit-ID: 8ZWASzu7Znv
This patch stop clearing mContentForTSF at unlocking the document because we should keep it until active composition is committed. If so, TSF/TIP won't be confused by content changes by JS. So, this is important for a11y of TIP users in some complicated websites like GoogleDocs, Facebook, etc.
Note that this patch doesn't work well without following patches. We need to stop notifying TSF of selection changes and text changed while mContentForTSF is valid.
MozReview-Commit-ID: 9QOGZxdYU3I
