Tapping on push notifications opens a new about:blank page
Categories
(Fenix :: Push, defect, P2)
Tracking
(firefox119 affected, firefox120 affected, firefox121 affected, firefox122 affected, firefox123 affected)
People
(Reporter: raj.azharuddin, Assigned: m_kato)
References
(Blocks 3 open bugs, )
Details
(Whiteboard: [ux-fun-2024] [geckoview:m119?] [qa-triaged] [s2-list25?] [fxdroid] )
Attachments
(7 files)
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•1 year ago
|
||
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•1 year ago
|
||
raj.azharuddin@gmail.com could you please upload a screenshot of one of the notifications that exhibits this behavior?
Reporter | ||
Comment 3•1 year ago
|
||
Same notification from 2 browsers- firefox and Vivaldi
In firefox it is opening about:blank
Reporter | ||
Comment 4•1 year ago
|
||
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•1 year ago
•
|
||
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!
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Reporter | ||
Comment 6•1 year ago
|
||
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
Reporter | ||
Comment 7•1 year ago
|
||
Also it's same website same notification..
Battery saver disabled for all 3 apps
Comment 8•1 year ago
|
||
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?
Reporter | ||
Comment 9•1 year ago
|
||
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•1 year ago
|
||
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•1 year ago
|
||
(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)
Updated•1 year ago
|
Reporter | ||
Comment 12•1 year ago
|
||
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.
Reporter | ||
Comment 13•1 year ago
|
||
It's really sad to see even after sharing videos/evidence no one is acknowledging 😔
Comment 14•1 year ago
|
||
Still affects me with 114.2.0 on Pixel 6 Pro / Android 13
Comment 15•1 year ago
|
||
Affects me too with 115.0.1 an Pixel 7a / Android 13
Same with Beta and nightly
Reporter | ||
Comment 16•1 year ago
|
||
Any update?
Comment 17•1 year ago
|
||
This bug is related to Service Worker Notification.
STR:
- Open https://tests.peter.sh/notification-generator/
- Find "Reaction Settings" , Set Action to "Only open a new window" or "Only open a new window (tel:).
- Click "Request Permission" and click "allow" in prompt dialog.
- Click "Display the notification"
- 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:+1202555010
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•1 year ago
|
||
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•1 year ago
|
||
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•1 year ago
|
||
ni? :owlish who has offered to look into picking an approach forward.
Updated•1 year ago
|
Comment 21•1 year ago
|
||
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.
Reporter | ||
Comment 22•1 year ago
|
||
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 😐
Reporter | ||
Comment 23•1 year ago
|
||
Hi team
Any update please 🙏😭
Assignee | ||
Updated•11 months ago
|
Assignee | ||
Comment 24•11 months ago
|
||
First look, serviceWorkerOpenWindow
doesn't wait for completion of GeckoSession.open
. So we need to fix some point to fix this.
Reporter | ||
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Comment 25•11 months ago
|
||
Assignee | ||
Comment 26•10 months ago
|
||
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•10 months ago
•
|
||
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.
Updated•10 months ago
|
Reporter | ||
Comment 28•8 months ago
|
||
Hi team
Any update? 😕
Assignee | ||
Comment 29•8 months ago
|
||
Updated•8 months ago
|
Assignee | ||
Comment 30•8 months ago
|
||
WebDriver API depends on ServiceWorkerDelegate
. But we can replace it with
BrowserDOMWindow
API.
Depends on D190661
Assignee | ||
Comment 31•8 months ago
|
||
Depends on D197134
Comment 32•8 months ago
|
||
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.
Assignee | ||
Updated•8 months ago
|
Comment 34•7 months ago
|
||
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.
Updated•7 months ago
|
Comment 35•7 months ago
|
||
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.
Assignee | ||
Comment 36•7 months ago
|
||
Comment 37•6 months ago
|
||
Hello all,
This issue is still ongoing as of the latest version, 122.1.0 (Build #2016001831). Are there any updates?
Comment 38•6 months ago
|
||
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)
Assignee | ||
Comment 39•6 months ago
|
||
(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.
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Updated•4 months ago
|
Comment 40•4 months ago
|
||
UX Fundamentals bug for squad 1
Comment 41•4 months ago
|
||
Now 125 is also the affected version.
Comment 42•1 month ago
|
||
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.
Assignee | ||
Comment 43•1 month ago
|
||
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•18 days ago
|
||
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.
Updated•15 days ago
|
Comment 45•15 days ago
|
||
I can vouch, happening on a OnePlus Nord on UK Three network, whatever ROM is currently standard from them, and Firefox 128.0.3
Updated•14 days ago
|
Comment 46•13 days ago
|
||
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.
Description
•