This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This patch also renames:
EditorInputEventDispatcher -> mozilla::EditorInputEventDispatcher
And some variable names are renamed from aEditor or mEditor to aEditorBase or mEditorBase for making their types clearer.
MozReview-Commit-ID: 2FCXWpLMn8e
--HG--
rename : editor/libeditor/nsEditor.cpp => editor/libeditor/EditorBase.cpp
rename : editor/libeditor/nsEditor.h => editor/libeditor/EditorBase.h
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
It will use on ContentCache. Also, SetRangeFromFlatTextOffset issue will hanle on another bug.
MozReview-Commit-ID: 9Yu8bLlcZS5
--HG--
extra : rebase_source : c8eba70bdedf303b0fa649c1a609fe6120983e65
extra : histedit_source : 4189807b57ede13c1546e95052fcc298c8581d06
"ime-enabled-state-changed" notification was implemented for Android in bug 603848 but nobody currently observes this notification. Therefore, we can stop notify the observer service of this.
MozReview-Commit-ID: 3TNHf1xWo2l
--HG--
extra : rebase_source : 39c7e9e391cd6c9510785bca92020707714f4101
IMEContentObserver may have cache of normal selection. If it's available, IMEContentObserver should use it for computing absolute offset of WidgetQueryContentEvent whose mInput::mOffset is relative offset to selection.
This patch just improves the performance of such query.
MozReview-Commit-ID: KHLgCc2uQzs
--HG--
extra : rebase_source : 1367aee0aadb88258135690aa5a8591201129c27
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe