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
Refactor the dispatching code to be more streamlined, and add two
optimizations to the way we dispatch a call:
* avoid a pair of unnecessary calls to add/delete the global class ref,
when dispatching a static call to the Gecko thread without a class ref
parameter.
* avoid an extra allocation when dispatching to a proxy function.
Remove uses of UsesNativeCallProxy and UsesGeckoThreadProxy, now that
they are not needed.
Remove cases where we had to invoke a call in a proxy, because the call
is now specified to be invoked directly in the WrapForJNI annotation,
without the need to go through the proxy.
For SmsManager and AlarmReceiver, we no longer need to manually dispatch
everything to the Gecko thread because that's now handled automatically.
Implement checking the calling thread of a JNI call based on the
calledFrom attribute set in WrapForJNI. Also implement automatic call
dispatching based on the dispatchTo attribute set in WrapForJNI. This
eliminates the use of UsesNativeCallProxy and UsesGeckoThreadProxy.
Update the code generator and related classes in annotation processor to
use the new WrapForJNI flags. Also add some more sanity checking to make
sure the flags are used correctly.
Replace old flags in WrapForJNI usages with new flags. The calledFrom
and dispatchTo flags are set based on whether the method is native or
non-native, and how the method is used.
Also fix testEventDipatcher to respect NativeJSObject's calledFrom =
"gekco" flag, by moving a test to Gecko thread.
We need to register the Java UI thread in native code very early in the
startup process, before libxul registers its JNI entry points. So it
makes sense to register the Java UI thread in mozglue.
This must be able to reproduce with some IMEs which creates 0 length composition string. In such case, mTextRectArray isn't available, but mTextRectArray.GetUnionRectAsFarAsPossible() always assumes that it's valid and has at least one rect. Therefore, it can meet this crash.
Therefore, this patch makes that ContentCacheInParent::GetUnionTextRects() not use mTextRectArray when it's not valid nor doesn't have rects.
MozReview-Commit-ID: 2yLMo4lxI3Z
--HG--
extra : rebase_source : 3ef3f2c6ba6473fd3eefbd5c909c1ef6c51c76af
TargetClauseOffset is the offset from start composition offset. So we should add start composition to calaculate correct rects.
MozReview-Commit-ID: 4qCpKvw2Eb4
--HG--
extra : rebase_source : 1c11d5648987772ee684166ee715340ad90284c0
Because bug 1282866 removed Qt support but missed a bunch of things.
* * *
Bug 1285554 - more
--HG--
extra : rebase_source : c48d2485f1fdf1c961e08d91651bbca41e3a1a53
kVK_RightCommand is already defined in Carbon.framework in 10.12.
MozReview-Commit-ID: 5QWRK4Gokg8
--HG--
extra : amend_source : 14f4059ef2c7cabfc63c33c4cea92b2650b5bc48
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
Remove SENSOR_EVENT from GeckoEvent and implement it as a native method
in GeckoAppShell that is invoked by the sensor event listener in
GeckoAppShell.
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
The intention is that GeckoView consumers will not use browser.xul,
but instead geckoview.xul; and that they'll provide content URLs from
their assets/ directories. This lets them do things without modifying
the omnijar and in particular without setting Gecko's prefs *before*
Gecko startup.
MozReview-Commit-ID: 2QLQQ5RphFu
--HG--
extra : rebase_source : b80eb1b15a54dac3c19ba9c7bfe4f0ac7dae78c6
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
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
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
To optimize copy of text rect array, we should use mozilla::Move. Also, after using it, we should mark is invalid result into SetEventResult
MozReview-Commit-ID: HH9H7DhK12
--HG--
extra : rebase_source : 4e02ece73583306c386597bc92e203fa147cfcbc
extra : histedit_source : 726621cdaf262b9d173ae19d505575f10563cc36
Selection cache might be updated on commit string, so it should be updated correctly. Also, IMContextWrapper::OnSelectionChange() already has the check for composing using IsComposing().
MozReview-Commit-ID: 2n3f3I3aAjg
--HG--
extra : rebase_source : 5bd43d723a3170864dd7ac05c9101aaedd7dfac6
Use new event to update cotent process's cache.
MozReview-Commit-ID: CexTXW4knMQ
--HG--
extra : rebase_source : 525a8b0a1fe6ef533e06f76ac5156e264b158c70
extra : histedit_source : 2a8c46a64eb5c6a7a05adc28917422c488b2b1c4
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
IMContextWrapper::OnDeleteSurroundingNative should output aOutput and aNChar correctly.
MozReview-Commit-ID: 46UrnGajnTG
--HG--
extra : rebase_source : 7ed7d3f389d492117e835c071bbea00f7ce4ff8d
TextInputHandler may dispatch keypress events after InsertText() is called if there was composition and it's committed by "current" keydown event. In that case, [NSEvent characters] may have the committing string. For example, when Opt+e of US keyboard layout started composition, Cmd+v causes committing the "`" character and pasting the clipboard text. Then, the "v" key's keydown event's |characters| is "`v". So, after InsertText() is called with "`", TextInputHandler shouldn't dispatch keypress event for "`" again. I.e., the KeyboardEvent.key value should be "v" rather than "`v".
For solving this issue, TextInputHandlerBase::AutoInsertStringClearer which is created at every InsertText() call should store the inserted string to TextInputHandlerBase::KeyEventState. However, for making the implemntation simpler, it should recode only when the inserting string is actually a part of [mKeyEvent characters]. Then, TextInputHandlerBase::KeyEventState can compute unhandled insert string at initializing WidgetKeyboardEvent.
So, finally, TextInputHandlerBase::InitKeyEvent() should be called via TextInputHandlerBase::KeyEventState::InitKeyEvent(). This ensures that all key events which may cause InsertText() calls are always initialized with unhandled string.
MozReview-Commit-ID: A9o8o9pV2XV
--HG--
extra : rebase_source : d99e9ab7633f45069d0a3940cc2b2b5ad859ea05
(Based on original patch by Chris Coulson.)
Replace session management through libgnome with direct use of libSM and
libICE. This allows xsmp session restore on gtk2 and gtk3 builds.
Changes in behaviour:
- It now only sends the "session-save" notification when the save style
is SmSaveLocal or SmSaveBoth. Saving internal state with a save style of
SmSaveGlobal is actually incorrect. This means that Firefox now
distinguishes between a normal session exit and a session exit with
session saving enabled.
- As "quit-application-requested" might pop up a dialog, it only does
this if the interact style is not SmInteractStyleNone
- "quit-application-requested" is only sent after sending
SmcInteractRequest and receiving an interact message.
- It defers closing the connection to the session manager until
the destructor, i.e after the "web-workers-shutdown" async shutdown
phase completes. This means that firefox shouldn't be killed too early
and lose data (*).
* It still might be killed prematurely if it takes too long to quit and
the session manager decides to timeout, but that's another story.
TextComposition should update its composition start offset after every DOM event dispatch with first clause's selection type if there is composition string.
MozReview-Commit-ID: HFkePci1PhU
--HG--
extra : rebase_source : c7af075115505b52e48d8bbd5f2dd1d9001fe36e
TextComposition needs to query first IME selection. Therefore, we need to add support to query special selection range with eQuerySelectedText.
First, WidgetQueryContentEvent::mInput should have mSelectionType which should be initialized with InitForQuerySelectedText() but unfortunately, there is no method for eQuerySelectedText. Therefore, this patch initializes WidgetQueryContentEvent::mInit::mSelectionType with SelectionType::eNormal in its constructor.
Next, ContentEventHandler needs to support to handle eQuerySelectedText with special selection types. However, we need to create 2 paths in some cases, one is for normal selection and the other is for special selections because there are no selection ranges may be usual case for special selections but not so for normal selection. Therefore, ContentEventHandler::InitCommon() becomes a little bit more complicated. ContentEventHandler::mSelection and ContentEventHandler::mFirstSelectedRange is initialized with the specified selection type but normal selection type is also necessary to compute the selection root since the selection root is computed from the first selected range which may not be anywhere if its selection type is not normal.
Finally, ContentEventHandler::OnQuerySelectedText() returns "there are no selections" as succeeded case in special selection type cases.
MozReview-Commit-ID: 9WzUx8b5piw
--HG--
extra : rebase_source : fb07b40748b594d36315f1fc21c0a02ff9f668bb
In an expression such as:
const auto& x = cond() ? AClass(...) : AClass();
the C++ standard specifies that the copy constructor of AClass is
invoked on the result of the conditional expression ([expr.cond]p6).
GCC does not honor this part of the specification, whereas clang does;
clang therefore complains about instances of code such as:
const auto& jstrVal = type == widget::PrefsHelper::PREF_STRING ?
jni::StringParam(strVal, aPrefName.Env()) :
jni::StringParam(nullptr);
as jni::StringParam is not copy-constructable.
The simplest solution that does not introduce unnecessary allocation
uses mozilla::Maybe to hold the temporary objects and to hide some of
the details of constructing objects in-place. The compiler may even be
able to optimize away some of the unnnecessary checks that Maybe
introduces (e.g. checking for whether the Maybe is a Some or None at
certain points).
ContentCache may store composition string's rects which are inserted by one or more older composition event. Even in such case, native IME, especially TIP of TSF, expects non-empty rects.
Therefore, if native IME handler uses "insertion point relative query", ContentCache should return non-empty rect as far as possible. For example, even if query offset or range is not in its rect array of composition string, ContentCache should adjust the offset into the stored range.
MozReview-Commit-ID: 7hcIqxOWFk2
--HG--
extra : rebase_source : 8b1572e01cc56e5596ffba4eac0f7d5818b85a89
For making WinMouseScrollHandler MOZ_LOG* environment variables aware, WinMouseScrollHandler should use LazyLogModule.
MozReview-Commit-ID: ERurkwVX2Fb
--HG--
extra : rebase_source : 4dd1b257b075eb32328f628edac3cbcc1cbf6210
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij
TextEventDispatcher::MaybeDispatchKeypressEvents() dispatches keypress events with passed event's mKeyNameIndex and mKeyValue values. I.e., setting mCharCode doesn't make sense in this case. Similarly, mKeyCode value is also ignored (overwritten by 0) if it's printable key's key event (mKeyNameIndex == KEY_NAME_INDEX_USE_STRING).
MozReview-Commit-ID: bdBQOlVKTs
--HG--
extra : rebase_source : 0786fb72ce8cc5468bbf3d4d1e5cadaa4586837e
For making TextInputHandler MOZ_LOG* environment variables aware, TextInputHandler should use LazyLogModule.
MozReview-Commit-ID: 9La229BFaJ1
--HG--
extra : rebase_source : f18f689ea6522f3300c5411bcd9e49d4c31143e4
This is preparation. TISInputSourceWrapper is created before starting XPCOM, however, when its first instance is created, TextInputHandler.mm tries to log all keyboard layouts and IMEs which are installed into the system. This would be problem if it uses LazyLogModule because it's initialized at starting XPCOM.
MozReview-Commit-ID: DWz8TylL175
--HG--
extra : rebase_source : f377530f6325d6fcf8f90be5d6856972e9d312e5
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
In e10s mode and during focus is in a remote process, ContentCache handles WidgetQueryContentEvent instead of ContentEventHandler. Therefore, for supporting selection relative WidgetQueryContentEvent in e10s mode, we need to support it in ContentCache too.
MozReview-Commit-ID: L5d5ilmpetG
--HG--
extra : rebase_source : 46d646677ac0a5803398d18efbfd667bc3bf0c17
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
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij
Also derive default widget style from widget path. r=?karlt
Patch from Bug 1250704 needs to land prior to this one.
--HG--
extra : rebase_source : b831bb11a7a0a00c4bf51f93e07a41f432c78ec1
This patch defines mozilla::SelectionType as an enum class. This is safer than nsISelectionController::SELECTION_* since setting illegal value to its variable is checked at build time. So, as far as possible, this should be used everywhere (but of course, this isn't available in scriptable interfaces).
And also this implements some useful methods for managing SelectionType and RawSelectionType which are implemented in layout/nsSelection.cpp because nsISelectionController is implemented by both PresShell and nsTextEditorState. Therefore, implementing one of them may make hard to find them. On the other hand, nsSelection.cpp is a better file name to look for them.
Note that this patch creates mozilla::Selection::RawType() for binding. Native code should keep using Selection::Type() but the binding code needs to use RawType() due to impossible to convert from SelectionType to RawSelectionType without explicit cast.
MozReview-Commit-ID: 81vX7A0hHQN
--HG--
extra : rebase_source : d9f88e217c713c60d1c2578ce6421c73ccba8650
Jim Chen
Andi-Bogdan Postelnicu
Carsten "Tomcat" Book
Martin Stransky
Makoto Kato
David Anderson
Andrew Comminos
Thomas Zimmermann
Tom Tromey
Tooru Fujisawa
Wes Kocher
kearwood
Ryan Hunt
Kearwood (Kip) Gilbert
Aaron Klotz
Andi-Bogdan Postelnicu
Masayuki Nakano
Dylan Roeh
Bob Owen
Markus Stange
Jonathan Kew
Bas Schouten
Jared Wein
Nicholas Nethercote
stefanh@inbox.com
Jimmy Wang
Benoit Girard
ojab
Chris Peterson
Benjamin Smedberg
Gregory Szorc
Kartikaya Gupta
Phil Ringnalda
Andrea Marchesini
Nick Alexander
Milan Sreckovic
Jeff Gilbert
Bill McCloskey
James Willcox
Chih-Yi Leu
Michael Layzell
Morris Tseng
Kit Cambridge
Josh Aas
Gerald Squelart
Brandon Cheng
Oliver Henshaw
Nathan Froyd
Daniel Holbert
Alexandre Lissy
Karl Tomlinson
Nicolas Silva
Jonathan Watt
Cervantes Yu
SUN Haitao
Jordan
Randall Barker
Eugen Sawin
Sotaro Ikeda
Jan Varga
Sebastian Hengst
eyim
Jonathan Kingston
Ralph Giles