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
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
These are no longer needed as we have the data we were looking for.
MozReview-Commit-ID: 3WlPng3mAwt
--HG--
extra : rebase_source : 73a390f85f5c0894d53a5e8ee10b19278af58282
extra : amend_source : 6a2b9ff4191715d0ac6e43f92af1e64c59123ac6
ContentCacheInParent::mPendingCompositionCount is now managed with composition events which TabParent received. However, TextComposition doesn't dispatch composition events after coming request to commit active composition. Therefore, composition is committed forcibly in a remote process over 255 times, the main process crashes.
It's the safest way to use TextComposition to manage ContentCacheInParent::mPendingCompositionCount.
MozReview-Commit-ID: DEhzYcK1zcW
--HG--
extra : rebase_source : a47891b1d620bbe4e380e73134ec6da5d21f4ea9
This patch is adapted from Tor bug 1517.
To offer some protection against timing attacks by JS content pages, in this
patch we round the various time-exposing APIs (such as Date and
Event.timeStamps) to the nearest 100 ms when the pref "privacy.resistFingerprinting" is on.
MozReview-Commit-ID: eGucM9nGTn
--HG--
extra : rebase_source : 3ee600b07943f3954e9a2a9561391f2f7821bb86
Between nsIDocumentObserver::BeginUpdate() and nsIDocumentObserver::EndUpdate(), IMEContentObserver can cache added nodes as a range if they are consecutive nodes. Even if a node is removed, a data node is changed or attribute is changed unexpectedly, IMEContentObserver can post text change of the added node range and handle it normally.
MozReview-Commit-ID: IttDHBkr92Y
--HG--
extra : rebase_source : f0849d5fab0b28bdfa311cf833a216d43b9215d2
IMEContentObserver can reduce the number of times to compute node offsets with caching all added nodes as a range. For that, it needs to know when it starts to update and ends updating the document.
nsIDocumentObserver is a subclass of nsIMutationObserver and IMEContentObserver is a mutation observer of editor's root content. Therefore, if we change IMEContentObserver to a document observer, each mutation observer method needs to check if the change occurs in the observing editor. Therefore, this patch implements document observer as its nested class and manages it as a member of IMEContentObserver.
MozReview-Commit-ID: HPSPfajxjnx
--HG--
extra : rebase_source : fd4bdcc24759040fb6c39317024049a3a924fc67
Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
nsRange::DoSetRange() adds/remove its root to/from mutation observer, initializes common ancestor, registers itself to the common ancestor, unregisters itself from old common ancestor, and notifies selection listeners of selection change.
However, those runtime cost is expensive but on the other hand, a lot of callers set both start and end of the range and that causes calling DoSetRange() twice.
This patch renames Set() to SetStartAndEnd() for easier to understand the meaning and make it call DoSetRange() only once.
MozReview-Commit-ID: FRV55tuBAgg
--HG--
extra : rebase_source : 67adf929cf119e2425f7d3741651217522094590
When we send out a prefetch request, we act as if the load came
from one of the possibly many documents containing <link> element
for the given URL. The docgroup assigned to this request is
derived from this document. Later, when the load finishes, the
OnStopRequest code runs in a runnable labeled with this
docgroup. OnStopRequest dispatches a load event to *all* the link
elements, including some that might be in different docgroups
from the OnStopRequest runnable. This generates an assertion.
To fix this, I decided to dispatch the load events
asynchronously. I'm hoping the extra round trip through the event
loop shouldn't hurt us too much since I doubt anyone actually
listens for these events.
MozReview-Commit-ID: FTkjuHO7RFp
When we send out a prefetch request, we act as if the load came
from one of the possibly many documents containing <link> element
for the given URL. The docgroup assigned to this request is
derived from this document. Later, when the load finishes, the
OnStopRequest code runs in a runnable labeled with this
docgroup. OnStopRequest dispatches a load event to *all* the link
elements, including some that might be in different docgroups
from the OnStopRequest runnable. This generates an assertion.
To fix this, I decided to dispatch the load events
asynchronously. I'm hoping the extra round trip through the event
loop shouldn't hurt us too much since I doubt anyone actually
listens for these events.
MozReview-Commit-ID: FTkjuHO7RFp
IMEStateManager should cache nsIWidget for sPresContext at caching sPresContext. Then, even if sPresContext has gone, IMEStateManager can clean up with the nsIWidget cache.
Unfortunately, editor has some bugs about calling IMEStateManager::UpdateIMEState(). That is, calling it *before* IMEStateManager::OnFocusChange(). In such case, this patch makes UpdateIMEState() ignore the call.
MozReview-Commit-ID: 1cydI03WyB8
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
This commit adds a telemetry probe to determine the percentage of pages
that ever have a 'mousemove' event listener added to the DOM. This is for
determining how often APZ key scrolling could handle interleaved mousemove
events.
A flag is added to nsPIDOMWindow to track whether a qualifying event
listener was ever added to the DOM for this window, and is updated by
EventListenerManager. There are several other similar flags to this.
The probe is reported in nsGlobalWindow::FreeInnerObjects() so that it
can be compared exactly with the non-passive keyboard listener APZ probe.
MozReview-Commit-ID: DqqCfrdRCGp
--HG--
extra : rebase_source : fad8159c28b587572a4191f7cbde1e97e166639c
This commit adds a telemetry probe to track the percentage of pages that ever
have a non-passive 'keydown' or 'keypress' event that could preventDefault()
APZ key scrolling of the root of a page.
A flag is added to each EventListenerManager to track whether it ever had
a qualifying event listener, and then in nsGlobalWindow::FreeInnerObjects()
the event targets that could preventDefault() a scroll are checked for this
flag. This check is done at nsGlobalWindow::FreeInnerObjects() so that the
DOM is still alive.
MozReview-Commit-ID: EkK3vxehZA5
--HG--
extra : rebase_source : 4642189d0065254cf74dfe8475403f0bf8210bca
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
When the dom.w3c_touch_events.enabled pref is set to "2" (autodetect) on Win/Linux,
it checks to see if the hardware supports touch events, and only enables the
DOM touch APIs if so. However, even if the hardware supports touch events, we
might have e10s or APZ disabled for other reasons, and in those cases we don't
actually turn on touch support in the widget (nsBaseWidget::RegisterTouchWindow
will not be called). So in those cases the widget will never actually dispatch
touch events, and the DOM touch APIs shouldn't be exposed either. This patch
implements this by checking the APZ state when deciding whether or not to
expose the DOM touch APIs.
MozReview-Commit-ID: EIvJh030b0X
To run JS in separate cooperative threads, we need to split up per-thread state
from per-runtime state. This patch does that for XPConnect.
MozReview-Commit-ID: 407SlJ7nR6v
Also implements :link, :visited, and :any-link more efficiently, and stops
matching :-moz-read-only in everything that is not read-write, which is kind of
dumb, and probably creates some artifacts.
MozReview-Commit-ID: 6BQqi7nAWdT
--HG--
extra : rebase_source : 39dc6b481b3a92942dc3732990d8b9040d8e6d84
Instead of copying and concatenating strings into an mDest buffer in
SamplerStackFramePrintfRAII, require callers to keep the string buffer alive
for the duration of the current scope, and store the pointer to the annotation
string in the ProfileEntry. During stackwalking, concatenate the label and the
annotation (separated by a space) and store the resulting string in the
profile buffer.
MozReview-Commit-ID: GEjcLrhhdvb
--HG--
extra : rebase_source : 683749421ee2122805a249cf413e882ee5f33331
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.
MozReview-Commit-ID: 4BLpo88gSZj
--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
According to ATOK's behavior, IME may send different line breaker from its platform's standard. Therefore, we should treat \r as \n too.
Additionally, currently, TextComposition doesn't allow to input \n with composition. However, this was added for preventing to see odd control characters as boxes with code point. Therefore, we should allow \n for IMEs. (It was allowed, this limitation is unexpected when I reviewed the patch to reject control characters in TextComposition.)
MozReview-Commit-ID: DzGSMgp89Av
--HG--
extra : rebase_source : 0644e5941a080583af8701546111fbf46ec646ec
Consolas is narrower than Courier New, so we must adjust some tests to accommodate.
* Change some tests from generic 'monospace' to 'Courier New' to continue using previous font metrics.
* selectAtPoint.html no longer needs one of its Windows-only code paths because Firefox on Windows now selects the same text as it does on Mac and Linux.
* 323386-1.html's intermittent assertion failure (bug 718883) now appears to be 100% reliable on Windows, joining Linux and Android.
* size-1-ref.html reftest needs a little fuzz because the horizontal line of the test image's '4' character is ~1 pixel shorter than the reference image's.
MozReview-Commit-ID: EB5wzhG178U
--HG--
extra : rebase_source : e7aca6d16c255e45bef5dca93fff6c09bce787c4
Since it's not just the EventStateManager that has access to modify
these EventStates bits.
MozReview-Commit-ID: 17EpfQT5M40
--HG--
extra : rebase_source : 6d5f7ecff2d41d66cbc23ea12e08dc6295e29875
Since it's not just the EventStateManager that has access to modify
these EventStates bits.
MozReview-Commit-ID: 17EpfQT5M40
--HG--
extra : rebase_source : 6d5f7ecff2d41d66cbc23ea12e08dc6295e29875
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
This test case should be triggered by pointerover and pointerout. Add new test API to fire mouse event at the specified position and refine the synthesized events fired to the test case to trigger it correctly.
MozReview-Commit-ID: DkLYrD6MwYc
--HG--
extra : rebase_source : f0ae002edcb6f39d301e83fea9bf1e74dc21c62a
ScrollAreaEvent extends a cycle collected class UIEvent. It also contains a cycle collected DOMRect member field.
MozReview-Commit-ID: D1xsod4es0r
--HG--
extra : rebase_source : 1da827caecec7748ba8d89743b3bab59ba0faa73