Issue metadata
Sign in to add a comment
|
WebPush - phone-number-URL crashes onclick
Reported by
beboek....@gmail.com,
Jan 14
|
||||||||||||||||||||
Issue description
Steps to reproduce the problem:
1. register a service-worker, subscribe to WebPush
2. send a push containing additional information for an URL using a telephone-number schema to open (e.g. 'tel:0170123456')
3. touch on the notification
4. the service-worker opens the URL in the onclick-event via: 'clients.openWindow(url)'
5. Chrome now crashes
What is the expected behavior?
Either:
1. The native Telephone app should open with the number filled, like clicking on a 'a' tag with the number as href (e.g: '<a href="tel:017012345">...</a>')
or:
2. Chrome should ignore the URL like any other invalid URL
What went wrong?
Chrome crashed
Did this work before? N/A
Chrome version: 70.0.3538.80 Channel: stable
OS Version: 8.0.0
Flash Version:
Whole code for the service worker onclick-handler:
self.addEventListener('notificationclick', function(event)
{
let url = "/";
const noti = event.notification;
if (noti.data && noti.data.url) {
url = noti.data.url;
}
event.notification.close();
event.waitUntil(clients.matchAll({
type: "window"
}).then(function(clientList) {
for (var i = 0; i < clientList.length; i++) {
var client = clientList[i];
if (client.url == url && 'focus' in client)
return client.focus();
}
if (clients.openWindow) {
return clients.openWindow(url);
}
}));
});
Code to trigger the notification:
.showNotification("Test", {data: {url:"tel:017012345"}})
,
Jan 16
,
Jan 16
(6 days ago)
@beboek.max: Could you please provide test url or sample file to test this issue further. Is this issue reproducible on latest build #71.0.3578.99. Above details along with screencast would help in further triaging. Thanks!
,
Jan 16
(6 days ago)
@chelamcherla Yes, the newest version also crashes. I've made a small testpage to re-create the issue: https://mbeboek.gitlab.io/push-crash/ Simply click on the SendPush button and subscribe to push, then a message should appear. Once clicked on it, chrome on mobile crashes. Both Firefox on Mobile, and Chrome on desktop simply do nothing or open an blank tab.
,
Jan 16
(6 days ago)
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 16
(6 days ago)
It also crashes for me when sending a "mailto:a.b@mail.com" url. All "normal" https/http url are working fine.
,
Jan 17
(5 days ago)
Tested the issue in Android and able to reproduce the issue. Steps Followed: 1. Navigated to https://mbeboek.gitlab.io/push-crash/ 2. Clicked on push, clicked on crash notification and observed crash of chrome Chrome versions tested: 69.0.3497.0, 70.0.3498.0 , 73.0.3672.0 OS: Android 7.0.0 Android Devices: Nexus 6 Using the per-revision bisect providing the bisect results, Good Build - 69.0.3497.0 Bad Build - 70.0.3498.0 Manual CL: https://chromium.googlesource.com/chromium/src/+log/69.0.3497.0..70.0.3498.0?pretty=fuller&n=10000 On performing per-revision bisect, observed culprit CL as https://chromium.googlesource.com/chromium/src/+/7a20ffc4e1f5cbb57336f2c5254f61eba56c231e. But this doesn't seems to be the right CL, hence assigning from manual CL Suspecting https://chromium.googlesource.com/chromium/src/+/56e2b19423bd8bfc79470df3aae8e6944993d9e2 from changelog. @ awdf: If this is not related to your change please help in assigning to correct owner. awdf@'s last visit is > 30 days ago, hence assigning to reviewer xunjieli@ Thanks!
,
Yesterday
(35 hours ago)
I'm not sure who owns it, but we can take a look. At the very minimum we should not crash. I suspect that the cause of the crash will actually be in some Java navigation code somewhere, which will be really hard to identify. Tracing the spec a bit, my read is that we're expected to proceed by launching the external application (the Dialer in this case) barring spoofing concerns: https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-url-scheme https://html.spec.whatwg.org/multipage/browsing-the-web.html#hand-off-to-external-software >> ...user agents should attempt to mitigate the risk that this is an >> attempt to exploit the target software, e.g. by prompting the user >> to confirm that the source browsing context's active document's origin >> is to be allowed to invoke the specified software This is a reasonable concern, because the user has no way of knowing whether they're in the Dialer or in a web app pretending to be the Dialer. We shouldn't show a dialog when clicking on a Web Notification. Similarly, we've deliberately chosen to restrict openWindow() navigations to in-browser actions, i.e. bypassing Android's Intent filters, so I'm not sure whether we'd want to launch an external application at all. Thoughts? |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Jan 15