This patch stops the widget code from passing along touch-derived contextmenu
events straight from Windows to Gecko, and instead lets the APZ gesture
detection code handle it. This allows the contextmenu event to be prevented
according to web standards, e.g. if the touchstart event is cancelled.
This changes to browser.js will affect both Linux and Windows, but the behaviour
implemented is in line with native Windows touch behaviour. We may want to
add an alternate codepath for Linux to better simulate "native" Linux behavior,
if there is such a thing for touch-derived contextmenu.
MozReview-Commit-ID: 18qzK15ic8E
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
--HG--
extra : rebase_source : 061e48e014a38b2a442bf736031febfe0b1e333d
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
--HG--
extra : rebase_source : 71db6b4b9f0ab979313398a8014bde992183e019
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
--HG--
extra : rebase_source : 0bfaef0bbffd72d661c84992cc8c842215e3407a
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
--HG--
extra : rebase_source : 19a6eeb2357825643497caf5a5298c55f08a0670
Also, changed the other paper size conversion code to be similar, as I think it is easier to follow.
MozReview-Commit-ID: 2PzzxevnQSz
--HG--
extra : rebase_source : 45d20a714a05425b9010b2f390cd417617243682
I think that we can drop nsIMEUpdatePreference::DontNotifyChangesCausedByComposition(), i.e., nsIMEUpdatePreference::NOTIFY_CHANGES_CAUSED_BY_COMPOSITION because it's now used only by TSFTextStore but TSFTextStore ignores if SelectionChangeDataBase::mCausedByComposition or TextChangeDataBase::mCausedOnlyByComposition is true (for supporting async changes in e10s mode). So, only issue is, dropping the flag might cause increasing computing TextChangeData cost during composition in TSF mode. However, now, it's already enough fast and even if it'd cause performance regression, we could add a hack with TextComposition's offset information. Therefore, we don't need to worry about the performance regression so seriously.
MozReview-Commit-ID: HNT3G4isONj
--HG--
extra : rebase_source : 164231023aa2a17ceab94d92fb49ba0a00dab429
Currently, all widgets request selection change notifications to IMEContentObserver. Additionally, IMEContentObserver needs to listen selection changes for caching latest selection for eQuerySelectedText. Therefore, it doesn't make sense to keep defining nsIMEUpdatePreference::NOTIFY_SELECTION_CHANGE.
If widgets didn't need selection change notifications, they could just ignore the unnecessary notifications.
Note that all widgets don't need selection change notifications if a plugin has focus and IMEContentObserver cannot observe selection changes in the plugin. Therefore, if IMEContentObserver is initialized with a plugin, it shouldn't listen selection changes (and doesn't need to notify widgets of selection changes).
MozReview-Commit-ID: FOVFFgA2nOz
--HG--
extra : rebase_source : 3e16d5023835f99f82934e754d2e7db70474f9ee
TSFTextStore should use insertion point relative query for getting character rect and caret rect while there is a composition because in such case, TSF must want to query a part of or around the composition. Therefore, it makes sense to use insertion point relative query since it adjusts the offset with the latest content information.
MozReview-Commit-ID: IVjZ4zqFUkr
--HG--
extra : rebase_source : e535ffa2c7649f16ffe7f761a9ed01b061848aa7
IMM always queries character rect or caret rect relative to insertion point. Therefore, it makes sense to use the new feature, insertion point relative query content events for them. Then, IMMHandler doesn't need to care mismatch between its cache and actual content information.
MozReview-Commit-ID: LCCrJkR77I8
--HG--
extra : rebase_source : c75f1b29e34e13df397de351909f07e2a95b6c5f
