This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
The test case uses double intervals to make sure there is enough time to wait for the scroll event before continuing the testing. However, it doesn't work while the first timeout is delayed and the second one isn't. Tweaked the test case to start the second timer when the first one timeout.
MozReview-Commit-ID: gvhtIpzauE
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
This patch declares a new default action, "horizontal scroll", this scrolls
content horizontally with deltaY of wheel events and ignores deltaX and deltaZ.
This is used for default action with Shift key in default setting except on
macOS. On macOS, legacy mouse's vertical wheel operation with Shift key causes
native horizontal wheel event. Therefore, we don't need to use this new
default action on macOS. Additionally, old default action with Shift key,
navigating history, is moved to with Alt key. This makes same settings between
macOS and the others. So, this is better for users who use macOS and another
OS and web app developers who check wheel events only on macOS or other
platform(s).
For simpler implementation, default action handlers moves deltaY values to
deltaX values temporarily *only* while they handle wheel events. This is
performed by AutoWheelDeltaAdjuster and restored after handling it
automatically.
So, in other words, even if default action is "horizontal scroll", web apps
receives wheel events whose deltaY is not zero but its content will be
scrolled horizontally. This is same as Chromium, so, this behavior shouldn't
cause any incompatible behavior with it.
MozReview-Commit-ID: E4X3yZzLEAl
--HG--
extra : rebase_source : e20d854c6b0a181ad4c9e7304bd9ad14256481ff
We can use Selection directly instead of nsISelection. It means that we don't need QI for nsISelectionPrivate. So IMEContentObserver should hold Selection instead if nsISelection.
MozReview-Commit-ID: 4jp9wWHRHRd
--HG--
extra : rebase_source : 9f4792cf75555b5aafdacfd8f137e68d9da86e04
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Smart Location Bar (a.k.a URL bar) has some features, loading inputted URL
directly, searching bookmark items and history items, and search inputted words
with registered search engine.
So, it does not make sense its inputmode is "url". E.g., neither showing URL
specific software keyboard nor switching IME open state automatically for
typing URL may not be expected in most cases.
Unfortunately, there is no proper inputmode value for Smart Location Bar.
Therefore, this patch uses "mozAwesomebar" value and accepts the value only in
chrome documents. This value should be handled by each native IME handler
properly.
MozReview-Commit-ID: 7vUnbpg91F2
Spec says we should throw an exception when setting pointer capture while the page has a locked element. Also, we should release all pointer capture when a pointer lock is successfully applied on an element.
MozReview-Commit-ID: CuUIPipJWB0
We don't need to call GenerateMouseEnterExit twice when handling pointercancel. The second one is redundant since we do some checks in GenerateMouseEnterExit. And we should call GenerateMouseEnterExit before removing the entry in mPointersEnterLeaveHelper, which is used in GenerateMouseEnterExit.
MozReview-Commit-ID: 844bIFkPYfj
Some pages might use neither a default submit element nor rely on implicit submission and instead implement their form handling with JS key event listeners.
On Android, most IMEs won't allow sending an "Enter" key press if we're using an actionHint of "next" as our default, so we now use "go"/"search" for the last single line text/number input that is not disabled.
MozReview-Commit-ID: ACC15OYtcTF
--HG--
extra : rebase_source : 5ee608ea576e31ca320c93631bdb5e25716d9199
IMEStateManager has a static instance of InputContext which has some nsString
instances. Then, their members will be released after XPCOM shutdown and
that is detected as unexpected destruction.
Therefore, IMEStateManager should release them by itself at XPCOM shutdown.
Using nsTSubstring::SetCapacity(0) is the simplest way to release only the
string buffers.
MozReview-Commit-ID: LMrQxQF9xPn
--HG--
extra : rebase_source : 7cbaf19b76be8db083c10270d0ee436a1c061ea2
Revise the pointer event implementation, includes
- Revise the implementation to fetch preference values.
- Separate the logic to get the pointer capturing frame to PointerEventHandler.
MozReview-Commit-ID: 7pdAr0XFNT2
Prevent default on pointerdown will stop firing the subsequent mouse events. Ignore the case that preventDefault by WebExtensions to avoid breaking some websites.
MozReview-Commit-ID: 9ztW1WfEg9a
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
nsIEventListenerChange::changedListenerNames is an nsIArray attribute that
contains nsIAtoms. Bug 1396693 made it `noscript` to help with nsIAtom
deCOMtamination (bug 1392883) but more changes are needed: that array
eventually needs to be changed to nsTArray<RefPtr<nsIAtom>>.
Turns out the attribute has a single use, in a11y code. That code merely
iterates over the list and counts how many atoms it contains that match
"onclick", "onmousedown", and "onmouseup".
So this patch moves that counting functionality inside nsEventListenerChange by
changing the attribute to `countOfEventListenerChangesAffectingAccessibility`.
This saves us from having to expose the array of atoms via XPIDL.
--HG--
extra : rebase_source : db8b628998d45209ab724555a74efe90f431d3ae
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
It a stateless wrapper around static methods in nsHTMLTags and nsHTMLElement,
and hence an unnecessary layer of indirection that just adds complexity and
slowness. This patch removes it, cutting almost 300 lines of code.
This requires making nsElementTable.h an exported header, to expose the
nsHTMLElement methods.
--HG--
extra : rebase_source : abbcb8e5001389affbf717092213b898673db07f
This isn't a super essential feature, and is just a change to try to bring us in
line with chromium and the spec. As this has apparent web compat issues, and
DataTransfer is a hard to test area, this patch moves the changes behind a pref,
which we can come back to turning on after we ship 57.
Currently, IMEStateManager::OnChangeFocusInternal() tries to sync the state
whether menu keyboard listener is installed between itself and active remote
process -- When menu keyboard listener is installed, it posts a message to
_only_ active remote process. When menu keyboard listener is uninstalled,
it posts a message to _only_ active remote process. So, it's not guaranteed
that active remote process at installing and uninstalling may be different.
If it's different, IMEStateManager in the old remote process believes that
menu keyboard listener is still installed. This is what the cause of IME
unavailable in a remote process.
Current approach must be wrong. IMEStateManager should manage menu keyboard
listener state only in the process which the listener is installed in. Then,
when menu keyboard listener is uninstalled, IMEStateManager needs to restore
the latest input context in the remote process without asking the remote
process.
Therefore, this patch does:
* stops IMEStateManager::OnChangeFocusInternal() posting message when menu
keyboard listener is installed and uninstalled.
* removes the message sender and receiver from PBrowser.
* cache the latest input context of active remote process in
IMEStateManager::SetInputContextForChildProcess().
* make IMEStateManager::SetInputContextForChildProcess() not set input context
when menu keyboard listener is installed in the process.
* tries to restore latest input context in the remote process in
IMEStateManager::OnChangeFocusInternal(). If there is no cached input
context, it does nothing and waits next SetInputContextForChildProcess() call.
* clears the cache when IMEStateManager::OnChangeFocusInternal() changes
active remote process to different one or nullptr.
So, this must improve performance at activating and inactivating memubar and
opening and closing popup menu in the main process.
MozReview-Commit-ID: EelKSPlaXdw
--HG--
extra : rebase_source : db7334b3c0d3ce87868450ee3179692027975bd6
When triggering an iframe load or starting to parse a document for an iframe, the main thread may often have some time before the new page has been created. Try to trigger CC/GC slice at such point in order to avoid collector later when page is already executing its JS
--HG--
extra : rebase_source : 806df0af1dbaefb1761134eca0bb7c6ade6ac1a9
This is required for deCOMtamination. The patch removes the only script use of
this attribute, which is a low-importance one in a test.
--HG--
extra : rebase_source : 65c29043fbd77e60b21398216593cc9788723dd5
There is no reason to keep StartBatchChanges and EndBatchChanges in nsISelectionPrivate since this is noscript method. And if moving it to Selection, we can remove virtual keyword.
MozReview-Commit-ID: Go6njiW3r2x
--HG--
extra : rebase_source : cb5bfce8312de7d49496e5f841e9786ff16102f6
With previous change, KeyboardEvent is dispatched even when invisible window
has focus. However, nsRootWindow::GetControllerForCommand() returns controller
for focused window even when the window is invisible because it uses
nsFocusManager::GetFocusedDescendant() to retrieve focused window.
Perhaps, we can assume that users won't expect to do something with invisible
window when they type some keys. Then, nsRootWindow::GetControllerForCommand()
should return controller for visible ancestor window if focused window is
invisible.
This patch makes nsFocusManager::GetFocusedDescendant() can return only visible
descendants. However, it already has a bool argument. Therefore, it should
have a flag instead of adding new flag. Most changes of this patch is replacing
its callers.
Then, nsRootWindow::GetControllerForCommand() and nsRootWindow::GetControllers()
should have a bool flag if it should return controller(s) for visible window.
This patch adds a bool flag for it. Fortunately, the interface isn't scriptable.
Finally, this patch makes nsXBLPrototypeHandler::DispatchXBLCommand() and
EventStateManager::DoContentCommandEvent() retrieve controller for visible
window since they are always handles user input.
MozReview-Commit-ID: GygttTHuKRm
--HG--
extra : rebase_source : 1341273c4606298cb9b890b9312d9f5c8a75d144
When an <iframe> element has focus and its sub document isn't scrollable, the
parent document should be scrolled instead.
MozReview-Commit-ID: 5LSVDHDQGtI
--HG--
extra : rebase_source : 0b22a426ef0e4ab662c941f6bc759679c1b92b19
In some cases, sFocusedIMEWidget may be nullptr but oldWidget still has
composition since IMEStateManager doesn't guarantee that NOTIFY_IME_OF_BLUR
is sent after REQUEST_TO_COMMIT_COMPOSITION nor REQUEST_TO_CANCEL_COMPOSITION.
Therefore, when it tries to clean up old widget's composition, it should refer
the old widget's IME notification requests.
MozReview-Commit-ID: 8kZvJbHfs5z
--HG--
extra : rebase_source : 3a1aab1023ab36e3668efd93b95fb5c8ccf2f21d
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
When setting value of <input type="text">, nsTextEditorState removes all
ranges of normal selection first. Then, TextEditor sets the value. Finally,
TextEditor collapses the selection at the end of the text.
In bug 1386471, we got that there are some problems to remove the call of
Selection::RemoveAllRanges() in nsTextEditorState. Therefore, we need another
approach to improve Selection::Collapse().
The approach of this patch is, when removing all ranges from normal selection,
Selection can cache an nsRange instance if there is an instance which is not
referenced from other than the Selection (i.e., it'll be removed when
Selection::Clear() is called). Then, Selection::Collapse() can reuse it. With
this fix, Selection::Collapse() can reduce allocation cost and may reduce some
other cost like adding it to mutation observer.
However, keeping nsRange instance may cause increasing mutation observer's cost
since nsRange will be adjusted its start node/offset and end node/offset with
mutation observer to guarantee that the range is always valid. So, we can
cache such range only when the caller (or its callee) will set selection range
later. Therefore, this patch adds Selection::RemoveAllRangesTemporarily()
and make only nsTextEditorState::SetValue() and
ContentEventHandler::OnSelectionEvent() use it.
MozReview-Commit-ID: FjWrbz4S1ld
--HG--
extra : rebase_source : 83677640525e0b1a84bdd7fce63ff4704b9cc22b
nsIContentIterator::Init() takes nsRange but it's too expensive for some users.
So, there should be another Init() which can be specified a range in DOM tree
with 2 pairs of nsINode* and uint32_t.
MozReview-Commit-ID: 6JXic0KOM2d
--HG--
extra : rebase_source : 28ff355a2aa0dcb5d65495806ef8c67f1da642ea
Allocating and initializing nsRange is too expensive especially for temporary
use. However, ContentEventHandler uses nsRange only for representing two DOM
points. So, it should use simpler helper class, RawRange, for reducing some
unnecessary runtime cost.
Note that this still uses nsRange for initializing nsIContentIterator. This
will be fixed by the following patch.
MozReview-Commit-ID: 5TUy6yJf7HA
--HG--
extra : rebase_source : c4eb58e8f37c408c75479e6961ba9225f8bcee77
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
https://github.com/w3c/uievents/issues/112
This is supported by all other UAs. In the past we had compatibility
problems when trying to add support, but it seems these might be fixed
if we make all arguments optional beyond the first.
The interface chosen for the method is from the spec, which has been
updated to match Chrome. This is also very similar to WebKit, but the
final four arguments are different from IE.
MozReview-Commit-ID: 36AeX1JwJTt
--HG--
extra : rebase_source : 28b298d370f0f9a5ab4090a71a2aae91f1d90025
When a remote process has focus and it loses focus,
IMEStateManager::OnChangeFocusInternal() sends NOTIFY_IME_OF_BLUR via
IMEStateManager::NotifyIMEOfBlurForChildProcess(). Therefore,
sFocusedIMETabParent and sFocusedIMEWidget are set to nullptr here. So, if a
window becomes active, REQUEST_IME_TO_COMMIT_COMPOSITION in
IMEStateManager::OnChangeFocusInternal() won't work because
IMEStateManager::NotifyIME() ignores the request because of coming from wrong
process.
Therefore, IMEStateManager::OnChangeFocusInternal() needs to send
REQUEST_TO_COMMIT_COMPOSITION with proper process information which is only
stored by TextComposition instance.
MozReview-Commit-ID: KNEvOoQtK1E
--HG--
extra : rebase_source : 2d0c9297a6ffd3e7883130c80deec0479212148e
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
They were just dropped from the spec:
https://github.com/whatwg/dom/issues/362https://github.com/whatwg/dom/pull/489
ErrorEvent we never supported anyway until it was added recently to
match the spec. PopStateEvent is not supported by WebKit, Blink is
planning to try dropping support, our telemetry shows usage is
basically zero, and we never supported any way to initialize it anyway.
The changes to Document-createEvent.html and Document-createEvent.js are
taken from upstream. The other wpt changes are new in this commit.
MozReview-Commit-ID: A6GzhLwL08l
--HG--
extra : rebase_source : 4bdcd605b179ea787985845e9b1c53f76ebc179a
This is the one event we don't support in createEvent() that Blink
doesn't want to drop support for because they see nontrivial usage:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1171
Supporting it shouldn't hurt us and might make us work better on
whatever the sites are that Blink is hitting.
MozReview-Commit-ID: FbfTd6AYnDg
--HG--
extra : rebase_source : f6bbcbd04af87349064b965814571e832932c130
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
Change the interface to GetAlowsInline to take an nsISupports* instead
of a string, and pass the nsIScriptElement directly. If we don't have an
element, then pass nullptr or the mock string created as an
nsISupportsString.
MozReview-Commit-ID: pgIMxtplsi
--HG--
extra : rebase_source : 4691643bb67ff6c78a74a4886a04c4816cff6219
In order to speed up Required/IsRequired(), instead of querying for the
@required attribute, we're now using the NS_EVENT_STATE_REQUIRED flag to know
whether an element's value is required.
For this to work correctly, we need to set NS_EVENT_STATE_REQUIRED earlier,
that is, in AfterSetAttr(), before any consumer of IsRequired(). We also need
to update or clear our required states when input type changes, since we may
have changed from a required input type to a non-required input type or
vice versa.
Note that NS_EVENT_STATE_REQUIRED/OPTIONAL is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: Bjiby9GqJSB
This is for adding a pref that will allow web content to have key listeners
and use keyboard APZ, if they are marked passive. This commit also reworks
the function names and comments to make them more accurate.
MozReview-Commit-ID: LGDaVQOK1CS
--HG--
extra : rebase_source : a6bb4b7fff3488dea62b9114aa164814c74561a4
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
Currently, IMEStateManager::OnChangeFocusInternal() sends blur notification to IME when a remote process has IME focus and focus is moving from the process. However, if IME wants to keep composition even during deactive and nobody will gets focus (i.e., all windows becomes deactive), IMEStateManager shouldn't send the blur notification because it causes committing composition.
Therefore, it should send blur notification only when focus is moving to a PresContext (that means that not all windows becomes deactive) or IME doesn't want to keep composition during deactive.
Then, even if another window becomes active next time, IMEStateManager can send "stop IME state management" message to the composing remote process and the remote process can commit composition normally.
Additionally, this patch ensures to send blur notification when IME focused TabParent or widget is being destroyed. This fixes new memory leak bug of this patch (sFocusedIMETabParent keeps grabbing the instance until shutting down in some mochitests).
MozReview-Commit-ID: KYiFGo970a8
--HG--
extra : rebase_source : c3de0df442420979414b47d8d20c7988c49b205b
When TextComposition::RequestIMEToCommitComposition() is called but the request is handled by native IME asynchronously, TextComposition synthesizes eCompositionCommit(AsIs) event to commit composition synchronously. (This behavior helps web apps which tries to commit composition from JS.) Then, TextComposition::DispatchCompositionEvent() should ignore following composition events which are actually sent from native IME.
However, if composition is in a remote process, TextComposition::DispatchCompositionEvent() in the main process doesn't discard the following events coming from native IME. Therefore, ContentCacheInParent is confused by this unexpected events. So, TextComposition::DispatchCompositionEvent() shouldn't send the following unnecessary composition events to TabParent.
Note that in remote process, composition is committed synchronously with the hack mentioned above and synthesized eCompositionCommit(AsIs) event of TextComposition::RequestIMEToCommitComposition() in the parent process looks like coming from native IME. Therefore, following composition events coming from native IME are not necessary for the remote process.
MozReview-Commit-ID: 2uKFxcAq88J
--HG--
extra : rebase_source : f4fc3f19c86b03813479e6751cc19424f361d537
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
nsGenericDOMDataNode::SetData uses GetFlatTextLengthInRange. But GetFlatTextLengthInRange still use nsIDOMNode. It means that we need additional QI twice. So we should use nsINode version directly instead.
MozReview-Commit-ID: 3FX0uPGh53O
--HG--
extra : rebase_source : 1a4689ae8744062af8cc1f112b89075ddf3e1271
This patch fixes a simple mistake which was written when we support IME in e10s mode.
IMEStateManager::OnChangeFocusInternal() already has code which makes the method doesn't set IME state again when focus is not being changed, input context of the widget was already set by a remote process and our process is being activated. However, the condition of checking if input context of the widget was set by which process is reversed.
MozReview-Commit-ID: 61ZH0VnKqPq
--HG--
extra : rebase_source : 14eb8e276e6307ed30d018d4385c454f80c1e831
On macOS, we fall back eKeyPress event to native menu. Therefore, widget always requests a reply from remote process because it's difficult to check if the eKeyPress event will be sent to a remote process actually. If it's not sent to any remote processes, PresShell needs to dispatch the event into the DOM tree. Additionally, even if it's marked as "waiting reply from remote process", it needs to dispatch the DOM event in the main process first because we need to check if the key combination is reserved by chrome (if it's reserved, the eKeyPress event shouldn't be fired in the remote process).
Therefore, this patch makes EventStateManager::PreHandleEvent() resets the state when focused content isn't in any remote processes and the event's propagation hasn't been stopped.
Additionally, this patch makes PresShell::HandleEventInternal() checks WidgetEvent::PropgationStopped() with WidgetEvent::IsWaitingReplyFromRemoteProcess() before dispatching the event into the DOM tree.
MozReview-Commit-ID: FmgL3rCuQ8y
--HG--
extra : rebase_source : aa8d6b924fc78d1d9dd35a35c92976c35c758657
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
Protected EventStateManager::HandleAccessKey() walks ESMs to handle access key and EventStateManager::ExecuteAccessKey() looks for an accesskey which matches given char code values and execute an accesskey if it finds a target. These names are hard to understand what they do and we need an option not to execute accesskey but looks for a target. Therefore, this patch renames the former to WalkESMTreeToHandleAccessKey() and the latter to LookForAccessKeyAndExecute().
Then, they take a new bool argument, aExecute. When it's true, LookForAccessKeyAndExecute() executes found accesskey. Otherwise, i.e., it's false, they return true if they find an accesskey target for the given event in the process.
MozReview-Commit-ID: ETYbNmtTMGj
--HG--
extra : rebase_source : 553676384db5f795de1087a439f30eded11d22fe
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
As well as the obvious #ifdef stuff, the patch removes
TCPSocket::SetAppIdAndBrowser(), which means
{TCPSocketParent,TCPServerSocketParent}::{GetAppId,GetInIsolatedMozBrowser}()
can also be removed.
In order to speed up IsDisabled(), instead of querying for the @disabled
attribute, we're now using the NS_EVENT_STATE_DISABLED flag to know whether an
element is disabled.
It is safe to use the NS_EVENT_STATE_DISABLED flag for the following reasons:
- For form elements, nsGenericHTMLFormElement::IsDisabled() is only called on
form elements that can be disabled; form elements that can't be disabled
overrides IsDisabled() to return false directly.
And, before this patch, NS_EVENT_STATE_DISABLED flag is set by
nsGenericHTMLFormElement::IntrinsicState() if and only if IsDisabled() in all
cases when CanBeDisabled() is true, and when CanBeDisabled() is false then
IsDisabled() is always false and the flag is not set.
- For non form elements, optgroup and option have the flag matching
IsDisabled(). Note that option's IsDisabled() should also refer to optgroup's
(if it exists) disabled state, which was not done before this patch.
For this to work correctly, we need to set NS_EVENT_STATE_DISABLED earlier,
that is, in AfterSetAttr(), before any consumer of IsDisabled().
We also need to update the flag whenever the element's parent (e.g. fieldset or
optgroup) disabled state changes and when moving into/out of a parent
container.
Note that NS_EVENT_STATE_DISABLED/ENABLED is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: KSceikeqvvU
When the start node is a non-container node (i.e. <br>), and the start
offset is 0, we should not include a newline character for the node. For
example, for this range,
> <br/>hello
> \___/
the start node/offset is (<br/>, 0) and end node/offset is ("hello", 1).
The calculated range offset should be 0, and the range length should be
2: 1 for the <br/> newline character plus 1 for "h".
The patch also ensures this behavior for pre-mode nsContentIterator, for
both start and end node adjustments. For start nodes, we include any
non-container nodes with offset 0 in the range. For end node, we exclude
any non-container nodes with offset 0 from the range.
MozReview-Commit-ID: Lt2tCLbapq7
--HG--
extra : rebase_source : 7d86b6cf04581f1cd71fa85f8c8586541b3a84e9
Web standards use "Container" instead of "Parent". So, nsRange shouldn't use "Parent" for its members and methods.
MozReview-Commit-ID: Ho6N0diuWtE
--HG--
extra : rebase_source : ee4eb7068a68b118c7fe98e9e9e7fa9c9e7f13e2
When focus is moving from a remote process to different process (including to the main process), destroying IMEContentObserver in the focused remote process occurs later. I.e., NOTIFY_IME_OF_BLUR will be notified later. However, it may be too late for new focused process especially when destroying the focused widget.
Therefore, this patch makes IMEStateManager notifies IME of blur in such case.
MozReview-Commit-ID: GkypubVjn3H
--HG--
extra : source : 9f4bd86dff910c2e3c3ae35f3e883d809c4a204e
Requests to commit/cancel composition came from remote process with sync message. So, it may be too late. E.g.,
* If the process already sent new composition start but is not handled by the remote process yet.
* If the process already send commit message but it's not handled by the remote process yet.
* If focus was already moved to different process.
In the former 2 cases, the remote process should wait eCompositionCommit(AsIs) events for clearing TextComposition. Therefore, the requested should be treated as it's handled asynchronously.
In the last case, the remote process should commit composition with latest composition string in the main process because if the remote process commits composition with "current" composition string in it, user may lost some inputted text.
MozReview-Commit-ID: 18BUoZZq7HS
--HG--
extra : source : fd1585ad670a87d8b1ef8908931f3d4037751475
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
Currently, IMEStateManager always sets input context as set by current process even when it needs to adjust IME state when a tab parent for current focused IME process is removed. Then, input context for the widget is marked as for main process but the widget still have IME focus of a remote process.
For fixing this mismatch, IMEStateManager should set ORIGIN_CONTENT even when the tab parent is being destroyed.
MozReview-Commit-ID: C10YOAtkET4
--HG--
extra : source : 9430d123b19e0ac551c6048bb044fcfa22d13e45
When focus is moved from the main process to a remote process and there is active IME content observer (i.e., an editor in the main process has focus), IMEStateManager should destroy the active IME content observer because it may cause notifying NOTIFY_IME_OF_BLUR when the main process takes focus again.
MozReview-Commit-ID: BG3eZhxoWBW
--HG--
extra : source : 3447abd6be7ad112e97bfe860507a382c5d19385
Currently, it's not been managed yet that whether an event is posted to at least one remote process. So, for managing the state, BaseEventFlags should have a new bool flag and WidgetEvent and BaseEventFlags should have helper methods for it.
Additionally, this fixes a bug of nsGUIEventIPC.h. In a lot of ParamTraits, static_cast<Foo> is used for using base class's ParamTraits. However, it causes creating temporary instance with copy constructor. Therefore, WidgetEvent::MarkAsPostedToRemoteProcess() call in ParamTraits<mozilla::WidgetEvent>::Write() didn't work as expected.
MozReview-Commit-ID: DdafsbVfrya
--HG--
extra : rebase_source : 94205f3a7b36455c3c9f607c35866be033e627c1
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
ContentEventHandler::ExpandToClusterBoundary() doesn't check the return value of nsTextFrame::PeekOffsetCharacter(). Therefore, it may set its result to reversed offset. (e.g., when aForward is true and offset is 6, the result may be 5. When aForward is false and offset is 5, the result may be 6.)
For avoiding that, ContentEventHandler::ExpandToClusterBoundary() should check the result and only when it returns nsIFrame::FOUND, it should compute the proper offset.
On the other hand, it's too bad for ContentEventHandler that nsTextFrame::PeekOffsetCharacter() to return nsIFrame::CONTINUE_UNSELECTABLE when the user-select style is "all" because IME doesn't expect such cases.
Therefore, this patch adds additional argument to nsIFrame::PeekOffsetCharacter(), aOptions which is a struct containing bool members. The reason why it's not a bit mask enum is, such struct doesn't cause simple mistake at checking the value and the code is shorter. When mIgnoreUserStyleAll of it is true, this patch makes nsTextFrame not return nsIFrame::CONTINUE_UNSELECTABLE.
MozReview-Commit-ID: ACNNBTP92YZ
--HG--
extra : rebase_source : bd85da902e7fb59135d15514cb20a5599a4a640b
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process. Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.
It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.
For making uplift the following patch easier, the wrong patch should be backed out first.
MozReview-Commit-ID: IHWc7qZBQtc
--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
This commit updates FocusTarget to collect whether there are key listeners
on the event target chain for the focused element. This is needed because we
cannot do async scrolling when this is the case.
MozReview-Commit-ID: FhSyF6ffZ4
--HG--
extra : rebase_source : 3e7e8e88ddda1a6b9e8542c131fdbb37e578d7e1
This commit begins the work needed for tracking focus by creating two new classes,
FocusTarget and FocusState. FocusState is created and used by APZCTreeManager to
track the global focus information, while FocusTarget is created per layer tree and
sent to APZ with local focus information. Between the two we are able to figure out
what the correct scrollable layer is to use in response to a keyboard scroll.
See the comment in `FocusState.h` for more details on the architecture and things
needed in future patches to complete this.
MozReview-Commit-ID: F75VZv3i9U2
--HG--
extra : rebase_source : 3d04bced8e13a9884f0c1b320bad8ba2205d7011
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
