1484375 - Sync's "Send Tab" OS notification popup, ellipsized URL gets linkified by libnotify, and clicking it takes me to a bogus URL with ellipsis in it

Status: NEW

(Firefox :: Sync, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Have Firefox Sync configured on a machine running Linux (I'm using Ubuntu with Gnome 3 aka gnome-shell, if it matters)

 1. On another machine (or another firefox profile on the same machine), visit some URL with ?args in it - either of these will do (or any bug page):
     https://bugzilla.mozilla.org/show_bug.cgi?id=5000
     http://example.org/?abc

 2. Trigger "Send Tab To Device"  to send the tab to your Firefox-on-Linux  session. (On desktop, this is available in the ... menu at right edge of URL bar.)

 3. Back on your linux device: when the "Tab from [etc]" notification appears, *click the URL in the notification*.

ACTUAL RESULTS:
 - The notification has a modified version of the URL with everything after the "?" replaced with just "...".
 - And if you click the URL, you'll find that it's linkified and so you'll end opening e.g. "https://bugzilla.mozilla.org/show_bug.cgi?id=..." in a foreground tab, which is a broken page.

EXPECTED RESULTS:
 - Either the URL in the notification shouldn't be linkified, or the link should be correct.

Note: for comparison -- on Win10, it seems that the URL in the notification isn't linkified.  I can still click on it, but it just focuses the shared tab, because that's what happens when you click anywhere on the notification.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast 0.5 (ignore, next one is better)

Here's a screencast showing the bug. Note that the correct tab *also* gets opened (as tab #2 in my window), but it's not what I end up seeing -- instead, Firefox takes me to a new tab with the bogus URL with the actual string "..." at the end of it.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast 1 of me sending "https://bugzilla.mozilla.org/show_bug.cgi?id=5000" to this machine and clicking on the linkified part of notification

er, attached the wrong screencast -- here's a better one where the window's a bit wider so you can clearly see the bogus "..." at the end of the URL in the address bar.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Sorry for the delay :( This had me confused for a while, but based on the screenshot it appears something has transformed the text in that notification to a URL - so I expect that clicking on the background of the notification will do what we expect (ie, just focus the tab we've already opened) but clicking on the link is opening it.

Best I can tell, our alert service has no support for this, so I was assuming the Mac's backend must be doing this - but I can't reproduce it on my mac - I just get a notification showing text and the URL isn't rendered as underlined or otherwise treated as a link, and clicking anywhere on the notification just focuses the tab we've already opened. I also can't find any bugs on file that might have explained this change in behaviour.

So Daniel, I hate to ask, but can you still repro?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Mark Hammond [:markh] from comment #3)

I expect that clicking on the background of the notification will do what we expect

Unfortunately, clicking on the background of the notification has no effect at all on Ubuntu/Gnome.

based on the screenshot it appears something has transformed the text in that notification to a URL

Yeah. For what it's worth, I confirmed that it is possible to get notifications to show without having URLs forcibly linkified. I used the command-line tool zenity which lets you spawn dialogs/notifications of various sorts, like so:

zenity --notification --text="https://example.org"

...and that does indeed show an OS notification of the same type that we show, with the URL as plain text (not clickable), which is what we'd like to do. So, that's a good sign -- hopefully the linkification is being done by some piece of the pipeline that we can configure.

So Daniel, I hate to ask, but can you still repro?

Yup, I can. Just tested using the example.org URL from comment 0, sent from my phone to my laptop (running yesterday's Nightly on Ubuntu 19.10), and I end up looking at a new window with URL http://example.org/?…

Comment 5

[Mark Hammond [:markh] [:mhammond]]

This is getting difficult :) This appears to be a feature of libnotify and I can't work out how to disable it. For example:

% notify-send hello "Text is https://example.com"

Displays a notification with the test linkified - and I can't find any options or documentation for libnotify to prevent this. However, I also can't find this documented anywhere. On my linux box, libnotify reports it has the 'body-markup' capability, but the docs for libnotify imply that this just means you can use <a href=...> markup in the body to get the linkify. So I instrumented nsAlertsIconListener.cpp to make sure we weren't doing this somewhere, and we aren't - and the notify-send example above implies there's some magic going on.

(I didn't try to use zenity, but I wonder if that cmdline was creating a notification with only a title and no body? In my experiments, URLs in the title were never linkified.)

Also, libnotify will itself truncate long URLs and do the right thing with them - so in theory we could just decline to truncate URLs if we knew libnotify was going to linkify them - but we don't. We can't even be sure that XUL-based notifications are going be used, and even if we were, the "capabilities" of libnotify aren't exposed to us.

So I'm really running out of ideas - so maybe not truncating on Linux and keeping our fingers crossed that this does the right thing, or when it doesn't the end result isn't too horrible, is the best we can do?

ni? Lina because I notice she did work with libnotify and alerts in general a few years ago, so she might have ideas or thoughts around this, or know someone else who might understand this better than me.

Comment 6

[Lina Butler (ex-Mozilla)]

Ooof, I'm not sure, either—Karl (CCed) might know more, but it looks like we aren't the only ones to run into that problem.

Platform sniffing for Linux would definitely be the easiest fix. We couldn't use the libnotify backend on stock Ubuntu for a while, because Unity's libnotify notifications didn't support clicking on them (via the actions capability—which sounds like is what Daniel ran into), so that might be a concern. That might be different now that Ubuntu uses stock GNOME, though.

Daniel, can you please confirm if you're using Unity or GNOME?

Comment 7

[Lina Butler (ex-Mozilla)]

Some more thoughts on capabilities and sniffing! 😁

One way to expose capabilities in a generic way would be to extend nsIAlertsService with a hasFeature() method, or a features bitflag, or even Boolean constants for each feature. We can discuss the exact shape later.

It might be overkill, but I'm sure Send Tab wouldn't be the only consumer interested in that. On Linux, it would let nsAlertsService use the XUL backend right away, instead of trying the libnotify backend then falling back to XUL in case of an error (as on Unity with clickable notifications). We could also use it on macOS for implementing action buttons for web notifications. And, speaking of action buttons, the Notification#maxActions property would need to know if our backend supports buttons at all, and how many.

A middle ground between sniffing for Linux (which, on Unity, means we'd show the full URL in XUL notifications) and capabilities might be to add a backend string or enum attribute to nsIAlertsService. That would help fix this bug—we wouldn't truncate if backend == "libnotify"—but not as helpful for the other cases in the last paragraph.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to :Lina Cambridge from comment #6)

Daniel, can you please confirm if you're using Unity or GNOME?

I'm using GNOME ("gnome-shell"), which is the default on Ubuntu these days.

(Unity is dead per https://arstechnica.com/information-technology/2017/04/ubuntu-unity-is-dead-desktop-will-switch-back-to-gnome-next-year/ - maybe it's still possible to run it but you'd have to jump through hoops).

Comment 9

[Karl Tomlinson (:karlt)]

With KDE/Plasma, the URL shown via notify-send hello "Text is https://example.com" is not linkified, so that would seem to be a "feature" of the notification service, not libnotify. I don't know how this might be controlled - i guess a ZWNJ somewhere between characters of "http://" would break regexp matches.

Not truncating may be an option, but, on Mark and Daniel's systems, that still results in a linkified URL, which users are not meant to follow because there is already a tab.

dbus-monitor "interface='org.freedesktop.Notifications'" can be used to confirm what is sent, but we've already established that the truncation occurs before sending and linkification after.

There is the question of whether it is better to have a native notification with no action or a non-native notification with action. There are advantages each way.

Comment 10

[Mark Hammond [:markh] [:mhammond]]

(In reply to :Lina Cambridge from comment #7)

A middle ground between sniffing for Linux (which, on Unity, means we'd show the full URL in XUL notifications) and capabilities might be to add a backend string or enum attribute to nsIAlertsService. That would help fix this bug—we wouldn't truncate if backend == "libnotify"—but not as helpful for the other cases in the last paragraph.

One problem that might exist here is that IIUC, we might not know the backend - if I'm reading nsAlertsIconListener.cpp correctly, the backend used depends on both the capabilities of the platform and the characteristics of the specific alert - although nsAlertsService.cpp implies that once this condition is hit, XUL will be used for all following alerts, so :shrug.

(In reply to Karl Tomlinson (:karlt) from comment #9)

With KDE/Plasma, the URL shown via notify-send hello "Text is https://example.com" is not linkified, so that would seem to be a "feature" of the notification service, not libnotify. I don't know how this might be controlled - i guess a ZWNJ somewhere between characters of "http://" would break regexp matches.

Yeah - another even simpler option might be to remove the protocol entirely on Linux - we already do that for http:// links in an attempt to have the text in the notification be the same as what the URLbar shows.