1825910 - Tapping on push notifications opens a new about:blank page

Status: NEW

(Fenix :: Push, defect, P2)

Description

[raj.azharuddin]

User Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/113.0 Firefox/113.0

Steps to reproduce:

I click the push notifications, instead of opening the webpage it is opening a new tab with about:blank in the address bar (blank page)

Actual results:

Opened a blanked page

Expected results:

Should open the respective site

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jmahon, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Joe M [:jmahon]]

[e-mail] could you please upload a screenshot of one of the notifications that exhibits this behavior?

Comment 3

[raj.azharuddin]

Attachment: Screenrecorder-2023-04-18-10-31-37-746.mp4

Same notification from 2 browsers- firefox and Vivaldi
In firefox it is opening about:blank

Comment 4

[raj.azharuddin]

And one more thing, if firefox browser is not opened or not in recent application list, on clicking the push notifications it is simply opening the browser whereas in other chromium browsers it is not only opening the browser but also opening the page which triggered push notifications

Comment 5

[Andrei Mocirean]

Hello,
I was not able to reproduce the issue on latest Nightly from 20th of April 2023 (114.0a1) nor other Firefox versions (Firefox Beta 113.0b5, Firefox RC 112.1.0).
Even with Firefox being force closed from Android' Settings, the webpage present in the video still opens normally.
Device used for testing: Google Pixel 7 Pro (Android 13).
Could you please try to install the latest Nightly version on your device and see if it works as intended? Also, please let us know the device you used when reproducing the issue, as it would help us for further investigation.
Thank you!

Comment 6

[raj.azharuddin]

Attachment: Screenrecorder-2023-04-20-21-37-56-927.mp4

I have installed all 3 firefox browsers- main, beta and nightly
It is working only in the main browser but broken in beta and nightly...so I believe whatever bug introduced in nightly it got replicated to beta already.
Attaching video.

My device: poco f4 5g
Miui 14 Android 13

Comment 7

[raj.azharuddin]

Also it's same website same notification..
Battery saver disabled for all 3 apps

Comment 8

[Joe M [:jmahon]]

Triaging this as an S3 for now, because it seems like this doesn't affect all users or all websites in a reproducible way.

raj.azharuddin do you see this behavior for any other websites?

Comment 9

[raj.azharuddin]

Same behaviour for all push notifications..this issue started like more than 2 weeks ago I always thought to report then I thought someone might have already.

Another bug I see in normal browsing mode media notification not showing whereas in private mode showing, this also started along with the push notifications bug. Maybe I will file a new case for this

Comment 10

[Adina Petridean]

Not reproducible on the latest Nightly 114.0a1 nor other Firefox versions (Firefox Beta 113.0b5, Firefox RC 112.1.0).
Device used: Poco M4 Pro (Android 12)

Comment 11

[Joe M [:jmahon]]

(In reply to raj.azharuddin from comment #9)

Same behaviour for all push notifications..this issue started like more than 2 weeks ago I always thought to report then I thought someone might have already.

Another bug I see in normal browsing mode media notification not showing whereas in private mode showing, this also started along with the push notifications bug. Maybe I will file a new case for this

raj.azharuddin, could you check Android system settings for what notification permissions you have enabled for Firefox Beta? I don't know why private mode media controls would work differently from non-private mode media controls, but we have indeed had some users reporting issues with the new notification permissions system that Android 13 introduced - perhaps your issue is also connected to that.

(We're going to be working on improving notification permission handling, but that's a larger-scale effort that won't be a good solution for your current problem)

Comment 12

[raj.azharuddin]

Hello Joe
Sorry for any confusion...media notification issue is being handled through another bug 1827583
This bug was created for push notifications which works in the main firefox version but in beta and nightly on clicking push notifications it is opening about:blank page. I have attached videos also.

I am using poco f4 5g with Android 13. Hence requesting to test with any Xiaomi phone with Android 13.

Comment 13

[raj.azharuddin]

It's really sad to see even after sharing videos/evidence no one is acknowledging 😔

Comment 14

[DuckDuck]

Still affects me with 114.2.0 on Pixel 6 Pro / Android 13

Comment 15

[juergen.sch]

Affects me too with 115.0.1 an Pixel 7a / Android 13
Same with Beta and nightly

Comment 16

[raj.azharuddin]

Any update?

Comment 17

[jackyzy823]

This bug is related to Service Worker Notification.

STR:

1. Open https://tests.peter.sh/notification-generator/
2. Find "Reaction Settings" , Set Action to "Only open a new window" or "Only open a new window (tel:).
3. Click "Request Permission" and click "allow" in prompt dialog.
4. Click "Display the notification"
5. Click Notification in status bar

If everything work as a charm, it will either open a new tab which url is https://tests.peter.sh/notification-generator/ or switch to dialer app with
tel:[phone]
Reference: https://github.com/beverloo/peter.sh/blob/master/tests/notification-generator/sw.js#L73-L78

---

Some digging：
Fenix Part handle correctly on opening Notification.
in https://github.com/mozilla-mobile/firefox-android/blob/main/android-components/components/feature/webnotifications/src/main/java/mozilla/components/feature/webnotifications/WebNotificationIntentProcessor.kt#L31
and https://github.com/mozilla-mobile/firefox-android/blob/main/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngine.kt#L570

then goto GeckoView part
https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebNotification.java#156
https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#801

and then goto Gecko part (handle alertclickcallback in ServiceWorkerNotificationObserver)
https://searchfox.org/mozilla-central/source/dom/notification/Notification.cpp#1227

and goto website's sw part
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/notificationclick_event

It looks like the keypoint is that website's calling to clients.openWindow may not work properly on Fenix/GeckoView.

Comment 18

[jackyzy823]

Either one may be wrong:
Fenix part: https://github.com/mozilla-mobile/firefox-android/blob/main/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/serviceworker/GeckoServiceWorkerDelegate.kt#L27

GeckoView part: https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntime.java#260

I guess Geckoview part

                .accept(
                    session -> {
                      if (session != null) {
                        if (!session.isOpen()) {
                          session.open(sRuntime);
                        }
                        result.complete(session.getId());
                      } else {
                        result.complete(null);
                      }
                    });

should be

                .accept(
                    session -> {
                      if (session != null) {
                        if (!session.isOpen()) {
                          session.open(sRuntime);
                        }
                        session.loadUri(url); // here
                        result.complete(session.getId());
                      } else {
                        result.complete(null);
                      }
                    });

---

Interesting finding:

Previously session.loadUri(url); exists , however it has been removed in https://phabricator.services.mozilla.com/D171756 aka https://hg.mozilla.org/mozilla-central/rev/e832a10b85257e2a25842d57e4ab2fe38ddcfa12

Comment 19

[Nika Layzell [:nika] (ni? for response)]

When you call clients.openWindow, we create a new session internally within Gecko and then ask the frontend (in this case GeckoView) to bind to it. The load is started within Gecko itself, which is why we shouldn't be calling session.loadUri in that code, and it was removed in bug 1810619. The code in Gecko is supposed to wait for the new session to be created, and then start the load in that session itself (from WaitForLoad, which also starts the load: https://searchfox.org/mozilla-central/rev/7a642b487e4b93309285e2eb235f87a0d4b86518/dom/clients/manager/ClientOpenWindowUtils.cpp#357). Doing it this way is important to ensure that the API behaves as expected, and that the load is exactly the one requested by the service worker.

Unfortunately, it appears that the code is bugged a bit. The response from the ServiceWorkerOpenWindow call sometimes appears to arrive before the <browser> element has been inserted into the DOM in the newly created session window. This means that the call to GetPrimaryContentBrowsingContext will fail (due to there being no content BC yet), and the load attempt is aborted.

This is handled on the desktop side by using the normal nsIBrowserDOMWindow::CreateContentWindow function to create the new window. This method allows providing a nsOpenWindowInfo object to the newly created browser window, which can contain a callback to be called after the BrowsingContext has been inserted. As we wait for that callback, we always have the browser ready on desktop when starting the load.

The nsIBrowserDOMWindow interface is also implemented on Android, but like desktop it is associated with a specific browser window. The nsContentUtils::GetMostRecentNonPBWindow method which is used to get an existing window to open the window from does not work on Android, as GeckoView names windows navigator:geckoview instead of navigator:browser, so that codepath doesn't work on Android without some tweaking. Removing the Android special code-path and using navigator:geckoview on Android appears to fix the issue, and the load seems to happen as expected.

Unfortunately this approach does have the downside that it requires an existing window to create the new pop-up window off of, which may not be the case sometimes (I don't actually know what situations we'll have where there are no GeckoSession instances but there is a ServiceWorker running in GeckoView, but it may be possible. Attempting to open a notification after closing the GeckoView Example app actually appears to never even run the Service Worker). This also would be technically a breaking change to the GeckoView API, as embedders may expect that service worker open window requests are routed through the ServiceWorkerDelegate API, rather than the NavigationDelegate API for an arbitrary GeckoSession.

There are various ways which we could fix this, though some may require breaking changes to the API. In an ideal world, we'd make the new browser be created using a nsIOpenWindowInfo similar to what we do for desktop and calls through NavigationDelegate. That gives us the callback when the content BrowsingContext is inserted in a consistent way, as well as control over other potentially important attributes like container tabs in a consistent manner. Doing this would unfortunately be a breaking change however, as unlike NavigationDelegate's API, it is currently technically possible for the ServiceWorkerDelegate API to return an already-opened GeckoSession, meaning that we cannot control its ID from Gecko.

If not breaking compatibility is paramount here, and we're willing to accept technical debt and this codepath being very different from others, we could instead add manual logic to wait for a document load in the case where we can't find the PrimaryContentBrowsingContext specifically on Android.

Comment 20

[Nika Layzell [:nika] (ni? for response)]

ni? :owlish who has offered to look into picking an approach forward.

Comment 21

[[:owlish] 🦉 PST]

This also would be technically a breaking change to the GeckoView API, as embedders may expect that service worker open window requests are routed through the ServiceWorkerDelegate API, rather than the NavigationDelegate API for an arbitrary GeckoSession.

This is not good :) Ideally, it would be nice to fix this without breaking the API (it's fine if we want to introduce a new ServiceWorker API and deprecate the previous one though, but it doesn't seem necessary to me in this case. There is no additional info we can ask from an app or pass to an app to get rid of this race condition - we need to fix the async flow here, in my opinion).

If not breaking compatibility is paramount here, and we're willing to accept technical debt and this codepath being very different from others, we could instead add manual logic to wait for a document load in the case where we can't find the PrimaryContentBrowsingContext specifically on Android.

I would go with this solution to solve the immediate users' need (it's not great to have this functionality broken), and we will need to investigate and re-design this more thoroughly in the future.

Comment 22

[raj.azharuddin]

Any update please? It's really said to see even after reporting the bugs months ago there is no resolution yet ..whenever you are introducing new feature it is breaking some other which is expected but what more surprising is the fix is taking months or years to fix! Ideally after each major changes you people must collect feedback from testers if any existing feature is broken or not, if not then only release but here the issue is happening first in debug, then replicated to nightky , then to beta and then to release and yet no one notice this till it reaches the release version 😐

Comment 23

[raj.azharuddin]

Hi team
Any update please 🙏😭

Comment 24

[Makoto Kato [:m_kato]]

First look, serviceWorkerOpenWindow doesn't wait for completion of GeckoSession.open. So we need to fix some point to fix this.

Comment 25

[Makoto Kato [:m_kato]]

WIP: https://treeherder.mozilla.org/jobs?repo=try&revision=1aa47a0751388439b379e835da9fafbc7d3c3794

Comment 26

[Makoto Kato [:m_kato]]

Attachment: Bug 1825910 - Re-implmenent OpenWidnow on GeckoView. r=nika!,#geckoview-reviewers!

GeckoSession.open opens new Chrome window. But since this is async method,
there is no way to know whether window open is done and browsing context is
ready.

Service worker's openWindow needs to wait for browsing context is ready after
landing bug 1810619. So we need it when we resolve GeckoResult of
GeckoRuntime.serviceWorkerOpenWindow.

Comment 27

[miralobontiu]

Attachment: about blank.mp4

I was able to reproduce this issue on all Firefox for Android versions: RC 119.0 build 2, Neta 119.0b9, and Nightly 120.0a1 from 10/23, with Xiaomi Mi8 Lite (Android 10).
I've tested the pushalert.co/demo website.
I'll confirm this issue.

Comment 28

[raj.azharuddin]

Hi team
Any update? 😕

Comment 29

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=de500069e4c02fc1bbb9fdda93dc867a96cdb5c1

Comment 30

[Makoto Kato [:m_kato]]

Attachment: Bug 1825910 - Part 2. Rewrite GeckoViewTestUtils.createTab not to depend on ServiceWorkerDelegate. r=#geckoview-reviewers!

WebDriver API depends on ServiceWorkerDelegate. But we can replace it with
BrowserDOMWindow API.

Depends on D190661

Comment 31

[Makoto Kato [:m_kato]]

Attachment: Bug 1825910 - Part 3. Deprecate ServiceWorker delegate. r=#geckoview-reviewers!

Depends on D197134

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D190661	Bug 1825910 - Part 1. Use OpenWindow on GeckoView. r=#geckoview-reviewers!	m_kato	nika: Back Jan 2, 2024

:m_kato, could you please find another reviewer?

For more information, please visit BugBot documentation.

Comment 34

[miralobontiu]

I can confirm this issue on all the latest builds: Firefox for Android 121.1.0 build 1, Beta 122.0b8, and Nightly 123.0a1 from 1/12 with a Google Pixel 6 (Android 14).
Tapping on the notification from the https://pushpad.xyz/demo openes a new about:blank page.
On desktop, tapping on the notification, opens a new page from pushpad.xyz.
On Focus Nightly 123.0a1 from 1/12, the "Sending..." message is displayed under the "Send notification" button, and the notification is not sent at all.

Comment 35

[CookieJaws]

Attachment: Bug on Xiaomi Poco F3 Android 13

Hello,

I was able to reproduce this issue on a Xiamo Poco F3 running Android 13 on Firefox version 121.1.0.
It happens from forced closed state and running in the background.
However it opens the homepage instead of a about:blank.

Comment 36

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=f0cb498e152d480d778a3992e703bc3ea6b58a45

Comment 37

[CookieJaws]

Hello all,

This issue is still ongoing as of the latest version, 122.1.0 (Build #2016001831). Are there any updates?

Comment 38

[Kagami Rosylight [:saschanaz] (they/them)]

Just wondering from DOM side: Clicking push notifications is expected to run Service Worker and the service worker script should decide to what to do within notificationclick event handler e.g. open a window. Will it still be the case with the patch stack here?

(Note that this part is not well tested in CI because currently there's no good way to programmatically click system notifications in a test)

Comment 39

[Makoto Kato [:m_kato]]

(In reply to Kagami [:saschanaz] (they/them) from comment #38)

Just wondering from DOM side: Clicking push notifications is expected to run Service Worker and the service worker script should decide to what to do within notificationclick event handler e.g. open a window. Will it still be the case with the patch stack here?

(Note that this part is not well tested in CI because currently there's no good way to programmatically click system notifications in a test)

Current implementation uses Java's delegation code in GeckoView, But this implementation is broken now since there is no way to wait for valid browsing context is available. At first, although I add a way to waiting for it, but nika rejects it then we should use same Desktop path if possible. So it means that we have to refactor nsIBrowserDOMWindow.createContentWindow. Desktop uses its method.

So until factoring fix is approval, I change patch series to plan changes now.

Comment 40

[Chris Peterson [:cpeterson]]

UX Fundamentals bug for squad 1

Comment 41

[fxzxmicah]

Now 125 is also the affected version.

Comment 42

[sf49ers65]

I'm getting this error on my S24 Ultra running oneUI 6.1 and the latest version of Firefox (127.0.2 released on June 25th).

Has there been any updates to it?

Thank you for your time.

Comment 43

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=38d6992f737fcff06379880e334b44549f33a380

At first, I think we can use desktop's API simply. But if no session, it may have no geckoview.xhtml window. So I re-implement openwindow using service worker delegate. it will be ready for review after running more tests

Comment 44

[collimarco91]

I am getting the same issue with Firefox v128 on Android here: https://pushpad.xyz/demo The notification is received successfully, but when I click it I get a blank page.

Comment 45

[David Smith]

I can vouch, happening on a OnePlus Nord on UK Three network, whatever ROM is currently standard from them, and Firefox 128.0.3

Comment 46

[David Smith]

Somewhere in Android there is a setting to assign which browser to be used as a helper app when an app needs to display a website, for example to sign in. (I'm not sure, it may be the same setting as default browser.) This is causing the Firefox issue to spill into other apps.