This bug implements and opens window.print() for Android in Nightly.
Adds "GeckoView:DotPrintRequest" and "GeckoView:DotPrintFinish" events.
GeckoView:DotPrintRequest requests a PDF of the current window.print
page for Android to print. GeckoView:DotPrintFinish releases the static
browser clone created by window.print. PDF generation was additionally
adjusted to get the expected canonical browser context when printing
iframes.
Differential Revision: https://phabricator.services.mozilla.com/D171159
This is semantically similar to the existing available() method, however will
not block, and doesn't need to do the work to actually determine the number of
available bytes.
As part of this patch, I also fixed one available() implementation which was
incorrectly throwing NS_BASE_STREAM_WOULD_BLOCK.
Differential Revision: https://phabricator.services.mozilla.com/D170697
Implemented the prefers-reduced-transparency media query for all
platforms.
Windows and Mac have specific settings which are used, others (Android
and Linux/GTK) have it enabled if prefers-reduced-motion is also enabled
as there is no dedicated setting to check.
Locked behind new pref `layout.css.prefers-reduced-transparency.enabled`,
off by default always for now.
Also added new WPT tests (none previously).
Demo video: https://goose.icu/firefox_prt.mp4
Test page: https://goose.icu/prefers-reduced-transparency
Differential Revision: https://phabricator.services.mozilla.com/D172424
Newer Android supports multiple refresh rate that is dynamically changed.
Actually, GeckoView will always pass the refresh rate value to vsync when
getting it first time.
So this fix changes that GeckoView gets the refresh rate when vsync is started.
Differential Revision: https://phabricator.services.mozilla.com/D168665
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
This is:
* An easier way for browser code to access it.
* Avoids having a bunch of per-platform implementations.
* We don't need to actually get graphics info for it to work.
So it should be a bit nicer over all.
Differential Revision: https://phabricator.services.mozilla.com/D168373
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
This changes the behavior in a few ways:
- the 'active' notification is now only fired when a new user event has been received by Firefox, rather than by any application on the entire system.
- the 'active' notification will fire immediately when Firefox receives a new event. Before the patch is was fired within 5s of the user returning on some plateforms (eg. Mac) and immediately on some other platforms that already called ResetIdleTimeout (windows, gtk, android). I'm not sure if these existing calls to ResetIdleTimeout are really needed, nor if they add significant overhead.
- when an idle observer has been notified of 'idle', it won't be notified again until Firefox receives events. Before the patch, if the user used other applications while Firefox was in the background, we would keep sending active and idle notifications to our idle observers. This behavior was probably initially intended when the nsUserIdleService was introduced to support the use case of instant messaging clients, but doesn't seem to match the expectations of the existing consumers of the service.
Differential Revision: https://phabricator.services.mozilla.com/D166306
This adds context to `CloseAlert()` such that explicitly closing the notification e.g. `notification.close()` can be differentiated from a tab or window implicitly closing the notification. This is necessary as we want notifications to persist after a tab or window is closed for Windows.
This change in behavior is necessary to match user expectations. Users expect notifications to persist in the system tray and do not expect notifications to be lost due to a tab being closed. The content of the message is more important than the interaction in that lens. This change is also necessary for parity with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D161024
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
APZ now ensures that GetHandledResult() is Unhandled when appropriate,
so the widget code doesn't need to special-case eIgnore any more.
Differential Revision: https://phabricator.services.mozilla.com/D164585
This effectively backs out the fix for bug 1746336, while keeping the test
added in that bug (PanZoomControllerTest#touchActionWithWheelListener)
passing using a different fix approach (remembering the eager status
and using it in the computation of the delayed result).
Differential Revision: https://phabricator.services.mozilla.com/D164114
Actually, we can get Android release version from JNI generator, so it is
unnecessary to use `AndroidBridge` to get it.
Also, this cleans up unused AndroidBridge functions.
Differential Revision: https://phabricator.services.mozilla.com/D164431
There is no Core: Widget - Android now, so we should update bug component of
widget/android. Also, I add GVE for GVE path.
Differential Revision: https://phabricator.services.mozilla.com/D161413
On Android when SWGL is enabled, occasionally when switching tabs it
refuses to render the new tab. The user will instead be left with the
contents of the previous tab, or if they have just switched to firefox
they will be left with a black screen.
This occurs when SyncResumeResizeCompositor is called from java code
prior to the gecko compositor having been created. This results in us
delaying the call to UiCompositorController::ResumeAndResize().
Instead, once the compositor eventually gets created we call
UiCompositorController::Resume() (without the resize).
This means that the compositor widget is left with a zero size, and
RenderCompositorLayersSWGL bails early on compositing as a result.
To fix this, we cache the X, Y, width, and height arguments passed to
SyncResumeResizeCompositor. Then to resume the compositor when it
eventually gets created, we call ResumeAndResize() with the cached
values, rather than just calling Resume.
Differential Revision: https://phabricator.services.mozilla.com/D161046
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
In bug 1772839 we were seeing a large number of crashes due to
encountering a webrender error after exhausting all fallback
configurations. At least in some cases, this was due to the compositor
being resumed with an Android Surface that was already in an abandoned
state, meaning we can never succeed in creating an EGL Surface.
We added a check for this condition, and a workaround, to the
GeckoView java code. However, we are still seeing crash reports
matching this signature. To help determine whether these are also due
to the Surface being abandoned, or due to some other reason, this
patch adds a deliberate crash much earlier in the pipeline if we
detect an abandoned Surface.
Differential Revision: https://phabricator.services.mozilla.com/D160042
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
Olivia Hall
Nika Layzell
CanadaHonk
Makoto Kato
Calixte
Neil Deakin
Emilio Cobos Álvarez
Florian Quèze
Edgar Chen
Nicholas Rishel
Olli Pettay
Valentin Gosu
Marian-Vasile Laza
Sandor Molnar
Ben Freist
Razvan Cojocaru
David Shin
Botond Ballo
Daniel Baker
Cristian Tuns
Andreas Pehrson
Arturo Mejia
Jamie Nicol
Cosmin Sabou
Andrew Osmond