nsIEditor::GetDocumentIsEmpty() is a virtual code and there is non-virtual
method, TextEditor::IsEmpty(). So, any callers in C++ should use
TextEditor::IsEmpty() instead.
MozReview-Commit-ID: CQE8LP6XI96
--HG--
extra : rebase_source : e0027c3d71856adcd5fa7820bf936a6b405560c5
EditorBase::GetDocumentIsEmpty() is never called since it's overridden by
TextEditor::GetDocumentIsEmtpy() and never called directly. So, we can remove
its implementation.
Additionally, DocumentIsEmpty() is redundant. We can make it just IsEmpty().
MozReview-Commit-ID: CGsNzCHyVf
--HG--
extra : rebase_source : 3a8eeaf108bb387ea559e0643acfa96e26768577
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 3624ad04aa01dac1cd38efb47764dc3a8fbd5fbd
For the IPC work monitoring when textures become unlocked, we
need a Monitor equivalent of StaticMutex - this implements that.
MozReview-Commit-ID: IceQNeqVQ8f
--HG--
extra : rebase_source : 40b3f6f4934b83d28005722cf13b717ff81ef697
This patch will use DirectMapTextureSource to wrap the DataSourceSurface data for gpu access.
That could improve the texture uploading performance.
MozReview-Commit-ID: CGPFcCsR1RY
--HG--
extra : rebase_source : 750cc82f0de01289ee261e8d338cd7ea39a2e4c5
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 1d7c0700d1f24236102de467efd84af093687ab5
The DirectMapTextureSource could let the compositor to read the buffer directly.
That could get rid of some memory copy operations during texture uploading.
MozReview-Commit-ID: CHhoR96P7VG
--HG--
extra : rebase_source : fbca3bd3b8af29939626e697909cc67e9a5b34cc
The "mExternallyOwned" is used for gralloc buffer. We don't use the gralloc buffer now.
MozReview-Commit-ID: 7Gurpa3kdp0
--HG--
extra : rebase_source : 00d74c0bc8e8e164571e05942768cf18d9cbce4d
getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : 26a1801670e5554577f0f77b62667527f7b497bb
This is a follow-up to the changes made in Bug 1449968.
It makes more sense to preserve getRootBindingParent from shadowdom
logic because:
- getBindingParent for a node in a shadow root returns the host
component, so it was weird that getRootBindingParent would
return a node lower in the hierarchy
- getRootBindingParent is currently duplicated between toolkit
and devtools, and this made the implementations inconsistent
MozReview-Commit-ID: LNVEY8TzUKI
--HG--
extra : rebase_source : 4ae908bc9dfb2bbc951e9fda39049eb150a1df86
getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : d6fab834be4fb6ad9ba1cd73acf960cf0fe0d4d5
This is a follow-up to the changes made in Bug 1449968.
It makes more sense to preserve getRootBindingParent from shadowdom
logic because:
- getBindingParent for a node in a shadow root returns the host
component, so it was weird that getRootBindingParent would
return a node lower in the hierarchy
- getRootBindingParent is currently duplicated between toolkit
and devtools, and this made the implementations inconsistent
MozReview-Commit-ID: LNVEY8TzUKI
--HG--
extra : rebase_source : 4ae908bc9dfb2bbc951e9fda39049eb150a1df86
Key of TextCompositionArrary to search composition on widget is native IME
context. However, if TextInputProcessor dispatches composition events via
TextEventDispatcher, TextEventDispatcher::InitEvent() sets native IME context
of dispatching composition events to pseudo IME context (that's raw pointer
of TextEventDispatcher and process ID).
IMEStateManager::DispatchCompositionEvent() looks for existing TextComposition
with native IME context stored in WidgetCompositionEvent before dispatching
an event. However, after dispatching it, it looks for remaining TextComposition
instance with widget stored in WidgetCompositionEvent. Then,
TextCompositionArrary::IndexOf(nsIWidget*) will look for an instance with
the result of nsIWidget::GetNativeIMEContext() and this never returns actual
native IME context. Therefore, IMEStateManager::DispatchCompositionEvent()
always fails to remove TextComposition instance from the array even after
a test composition is finished.
This patch moves nsIWidget::GetNativeIMEContext() to nsBaseWidget to refer
nsBaseWidget::mTextEventDispatcher makes it return pseudo IME context if
TextInputProcessor has input transaction. Therefore, IMEStateManager becomes
always removes TextComposition from the array when every composition ends.
MozReview-Commit-ID: H1PCtPjBYJR
--HG--
extra : rebase_source : cbb3f3aae9954d65135d3840be8974fa30c4f7ff
This matches the behavior that is implemented in subdialogs.js where the load event handler is not removed until the new location is about:blank.
MozReview-Commit-ID: FZHW6Z63M2M
--HG--
extra : rebase_source : 010d884fb3bfc6dca63035c0125f3c2223847fcc
The CSSAnimation and CSSTransition interfaces are only needed to represent CSS
animations and CSS transitions returned by the
{Document,Element}.getAnimations() API.
Bug 1471814 introduced the dom.animations-api.getAnimations.enabled pref but
neglected to guard the CSSAnimation and CSSTransition interfaces behind this
pref, leaving them guarded by the dom.animations-api.core.enabled pref instead.
This patch updates the pref used to guard these interfaces so that when we turn
on the dom.animations-api.core.enabled pref by default we don't also end up
shipping these interfaces.
MozReview-Commit-ID: GjfvOltxlJy
--HG--
extra : rebase_source : 254cde7e9975d83b4ac94567725e6475f344e61d
At the moment this isn't actually async because we immediately require
the pid and block on launch anyway. It also crashes the entire browser
on otherwise recoverable launch errors, because code that wants the pid
isn't set up to handle that operation failing.
MozReview-Commit-ID: 5favGu34QCv
--HG--
extra : rebase_source : 3c81c53e1eb8ead353ef3477ed3ceea0f5edcbbe
These are no longer providing useful information. There are still a
noticeable number of failures on Windows, but we've narrowed them down to
within SandboxBroker::LaunchApp.
MozReview-Commit-ID: 9srWLNZq1Wo
--HG--
extra : rebase_source : db44114a7623e75f9efd629046d2118748352ed1
The PeerConnection mochitest wrapper had checks to make sure that the ssrc was reported as a string.
It is now an unsigned long and those tests needed to reflect that.
MozReview-Commit-ID: b7TzzG0I4J
--HG--
extra : rebase_source : 8c1665b1c8d8e2f0418a0be70d37c8ee10507c35
RTCRtpStreamStats.ssrc used to be a DOMString but is now an unsigned long.
When gathering this stat it needs to be constructed accordingly.
MozReview-Commit-ID: IOq9IQQxFVh
--HG--
extra : rebase_source : 3c5fc6144f6fa0435fc1ccce1a3fa371b9ffc162
At some point the type of the ssrc field changed to an unsigned long.
MozReview-Commit-ID: BmGXAaKQfim
--HG--
extra : rebase_source : b749797b5001b2ef867a239f61d22c69d5d22408
This patch will remove the dotted style focusring from TabBar. We have same tab
bar in the toolbox, but this tab has removed this style already.
(For detail, see bug 1444793)
MozReview-Commit-ID: CyazZkvKR6H
--HG--
extra : rebase_source : 821e606f54bfceba124af9d9c2585296f2ebc40e
Because of the START_STICKY flag, upon boot completed, the service
would be started by the system which would trigger onStartCommand
and the notification being shown on Android Oreo+ devices without
a following call to onHandleIntent.
MozReview-Commit-ID: EldSSzRb7Zd
--HG--
extra : rebase_source : 2f39e499b744188e48adbdf03e426d9d50c45262
