nsBaseAppShell already listens to xpcom-shutdown and calls |Exit| when it
receives it so we don't need to also listen for it in nsAppShell (which causes
two calls to xpcom-shutdown instead of one).
Differential Revision: https://phabricator.services.mozilla.com/D106209
nsBaseAppShell already listens to xpcom-shutdown and calls |Exit| when it
receives it so we don't need to also listen for it in nsAppShell (which causes
two calls to xpcom-shutdown instead of one).
Differential Revision: https://phabricator.services.mozilla.com/D106209
Note that this removes `window.ondeviceproximity` and `window.onuserproximity` which unexpectedly have been exposed unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D109160
This is a relatively easy way to improve the rendering with the
non-native theme while not regressing anything.
In the future, once non-native-theme is shipped and default everywhere,
I think we could provide something like:
bool nsITheme::GetShadowRect(nsIFrame*, StyleAppearance, LayoutDeviceRect&, RectCornerRadii&)
or such, where we can provide a precise rect + radii, and we would avoid
painting the shadow if the function returned false. That would allow us
to remove the native theme box shadow code path, and avoid WR fallback,
all at once.
Differential Revision: https://phabricator.services.mozilla.com/D109209
Thanks to the previous patch in this series we can now play video
using the non-essl3 GL_OES_EGL_image_external extension, therefore we
no longer require the essl3 version.
It is assumed that all android devices support
GL_OES_EGL_image_external (non-essl3). Even if that is not the case,
webrender is no worse off than layers in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D108909
Linux can also have high contrast (and mac, if you tweak prefs, but
let's assume that doesn't happen), so no reason we shouldn't share this
code.
One related simplification while I was doing this code move is that I
managed to remove the scrollbar "border" code. Turns out that Windows
was overriding ComputeScrollbarColors so that border and track colors
were always the same, and Linux was ignoring the border anyways, so with
this we can simplfiy the implementation a bit (as the Linux scrollbar
track / corner code can be shared with Windows now).
Differential Revision: https://phabricator.services.mozilla.com/D107863
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
It caused us substantial confusion investigating this bug under the belief that
StartRemoteDrawingInRegion may have been modifying the dirty region. None of our
existing widget code anymore uses the API in this way, so it makes sense to just
force this dirty region to be const so that we no longer support the assumption
and alleviate confusion in the future about how our widget code actually behaves.
Depends on D106246
Differential Revision: https://phabricator.services.mozilla.com/D106247
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
Actually, before starting composition, we always remove current selected
text. So it causes that input event is fired by this operation. This is
different of Blink.
`TextEventDispatcher` can set composition string using selected text when
starting composition. So we can reduce this input event.
Also, I mistake bug 1499076 fix. By this fix, we always fires input event
when having selected text even if it is unnecessary. This changeset has
this fix too.
Differential Revision: https://phabricator.services.mozilla.com/D105464
These services had their name added to components.conf:
* GfxInfo
* ThirdPartyUtil
* History
* HttpActivityDistributor
* UUIDGenerator
* ServiceWorkerManager
* PermissionManager
These services were added to componenets.conf under a different name:
* DirectoryService => Directory
* IOService => IO
* StringBundleService => StringBundle
* CacheStorageService => CacheStorage
* StreamTransportService => StreamTransport
* SocketTransportService => SocketTransport
These services weren't migrated to components.conf because only Rust
code uses them:
* RemoteAgent
* XULRuntime
* PrefService
These services weren't migrated to components.conf because they're unused:
* ToolkitChromeRegistry (used as ChromeRegistry)
* XULChromeRegistry (used as ChromeRegistry)
* Bits (completely unused)
These services were already available in components.conf but are still
used by rust code:
* URIFixup
These services weren't migrated because they will be handled in
subsequent patchsets:
* ObserverService
For the record, the following Services are being used by Rust code
and must remain until a Rust version of Components.h is written:
* RemoteAgent
* XULRuntime
* PrefService
* URIFixup
* ObserverService
* DirectoryService
* ThirdPartyUtil
Also the cocoa GfxInfo service was changed to use components.conf instead
of registering it at runtime, as all the other widgets were already doing
it this way.
Differential Revision: https://phabricator.services.mozilla.com/D105521
On some Mali devices we have encountered driver crashes caused by
calling textureSize(samplerExternalOES) in a shader without also
potentially sampling from the texture in the shader. ARM's suggested
workaround was to trick the driver in to thinking that the texture may
be sampled from (ie by sampling in a branch which is never dynamically
taken).
This is done by checking the value of a dummy uniform, and sampling
the texture if the value is non-default. Using a constant expression
did not work because the compiler would optimize the condition (and
therefore the sample) away.
Also re-enable webrender on Mali-72 and G76 devices, as it was blocked
due to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D105493
Note that quite a few Mali-Txxx devices still won't get webrender, due
to lack of GL_OES_EGL_image_external_essl3 support. Bug 1507074 tracks
lifting this requirement.
Depends on D105338
Differential Revision: https://phabricator.services.mozilla.com/D105339
Webrender has been enabled for most Adreno 5xx and 6xx devices for a
while now, but 505 and 506 were held back due to bug 1609191. We were
seeing a moderate number of crashes during what we suspected was
shader compilation.
The crashes on 505 and 506 have all but disappeared. Additionally,
after shipping to the wider release audience we saw the same crashes
on other 5xx devices, not just 505 and 506, but the numbers were never
so high as to be worrying. So we are safe to ship to 505 and 506 as
well.
Depends on D105337
Differential Revision: https://phabricator.services.mozilla.com/D105338
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
In bug 1688017 we blocked webrender on Mali-G76 devices due to reports
of crashes when playing video. Based on more reports by users and
further investigation of the crash data, it appears that Mali-G72 GPUs
are also affected by the same bug, but only on Android 11 (for both
GPUs). Crashes on other Mali GPUs and earlier android versions do
exist, but in much lower numbers.
Update the block to include G72 as well as G76, but only for Android
11.
Differential Revision: https://phabricator.services.mozilla.com/D105047
