In beta 50.0b1 pl on OS X 10.11.6 after sending tabs from Firefox for iOS the source (#2) in notification (en-US unnamedTabsArrivingNotification.body= "#1 tabs have arrived from #2.") is empty.

This is a problem caused by Firefox iOS not sending the title of the tab.

So bug 1289908 exists for the fact we don't get a title or a device name. (In reply to Edouard Oger [:eoger] from comment #1) > This is a problem caused by Firefox iOS not sending the title of the tab. If it is just the title missing, then we already attempt to use the URL instead. However, in this case it seems like the device name itself is missing. That seems strange as we get the device name from the "clients" collection. If that name is empty for iOS devices, then I'd expect the device name is also blank when we try and send a tab *to* the device. That would be bad if true, and would probably be bad enough to prevent us enabling "send tab to device" on desktop to ride the trains? I'll leave the needinfo on me - I really need a test iOS device (or emulator) to get to the bottom of this.

The root cause is that we're sending URL and title (if we know it), but not our own client ID. As a result, other clients don't know who sent the tab. There are thus two bugs here: * Polish the experience for when a title or a device name isn't found. After all, it's possible that we don't know the sender's client record at the moment we process an incoming command. We should show something like "Received new tab", not mentioning a device name. * Add the client ID to outgoing commands on iOS. That's Bug 1305895.

(In reply to Richard Newman [:rnewman] from comment #3) > * Polish the experience for when a title or a device name isn't found. After > all, it's possible that we don't know the sender's client record at the > moment we process an incoming command. We should show something like > "Received new tab", not mentioning a device name. The example Richard gave in IRC for this is: it's possible that the remote client sends a tab, then a week later another client sends a tab to you, then two weeks later your device syncs. The first client's record has TTLed out. So yeah, let's make this bug doing something sane in this scenario and leave bug 1305895 for getting the correct name. I think fixing this will be enough to allow us to get "send tab" riding the trains, especially if the expectation is that bug 1305895 will land sooner rather than later.

:rfeeley, any idea what we should say if we don't know the device name?

I'm looping in Robin, Anthony and Alex so our UX is consistent across platforms. Background for them: Users can send tabs between devices. Platforms have different standards for notifications, and we are also often missing information when sending tabs. See attached example. PLATFORM NOTIFICATION TEMPLATE Firefox icon Firefox name (mobile only?) Notification title (desktop only?) Notification body TAB META-DATA Page URL (will always have) Page title (will sometimes have) Sending device (will sometimes have) Questions: 1. What do we prefer to the title? "New tab" or "Tab received"? 2. Should title come first, if available, and then URL? 3. Do we need to include name of sending device? Seems like a lot to include even two of the three. I propose with ditch device and show: WITH TITLE ON DESKTOP: Tab received “Julia Breckenreid” http://breckenreid.com WITH TITLE ON MOBILE: Tab received: “Julia Breckenreid” http://breckenreid.com WITHOUT TITLE ON DESKTOP: Tab received http://breckenreid.com WITHOUT TITLE ON MOBILE: Tab received: http://breckenreid.com Thoughts?

Here's the bug where we last touched this part of the Android Product. We can rename the "title" on Android so this is where we use the device name, our fallback here is the App name. Which actually unifies nicely with the experience on say, iOS where it's always the App name. Here's a screenshot of the Android experience on N.

That's interesting - neither iOS nor Android display the name of the device the tab was received from.

Thanks Anthony! I combined it with a few others so all the platforms are together. I'd love to get Philipp’s opinion on our Windows notifications (which are not using Windows).

(In reply to Mark Hammond [:markh] from comment #8) > That's interesting - neither iOS nor Android display the name of the device > the tab was received from. We do on Android. It takes priority over AppName if we have it. That's also because we have the ability to set the "Title" of notifications whereas (I could be wrong) on iOS, we can't and so we have to use the AppName for the title of the notification.

(In reply to Ryan Feeley [:rfeeley] from comment #9) > Created attachment 8798035 [details] > received-tabs.png > > Thanks Anthony! I combined it with a few others so all the platforms are > together. I'd love to get Philipp’s opinion on our Windows notifications > (which are not using Windows). Hey Ryan, I'm not sure I understand the question. Is there something specific to this kind of notifications on Windows that you'd like my input on? Or is it about the way we do notifications on Windows in general?

Updated to show current Windows version.

To best determine what string we should use when device name is not available, I'm looking at the constraints imposed by the various platforms, and trying to come up with an approach that can apply to all of them. For the notification title, iOS forces the use of the app name (in our case, Firefox), so realistically this limits the number of items we can include to two. Because device are often not maintained, and are too long to be meaningful, I'm going to propose that we omit them entirely. Because titles are often very long, and likely to be truncated, I'm also going to propose that we omit them entirely. I think we should focus on the two things that matter: 1. What is this notification about? (Firefox has many kinds of notifications, we need to let the user know what this is about) 2. Now that I know that I am receiving a sent tab, what is the content? For #1 I propose we stick with "Tab received" (which complements the "Tab sent" notification we may use when sending. For #2 I propose we strip the http:// or https:// and simply show as much of the URL as possible. For Windows, Mac, Android this will look like: |Firefox| Tab received | icon | breckenreid.com/portraits/u7th… For iOS this will look like: |Firefox| Firefox | icon | Tab received: breckenreid.com/por… This keeps it simple, consistent across platforms, and avoids the complexity of degrading gracefully when device name and/or page title are not available. Make sense?

This seems to make sense. I agree that standardization is best for the UX.

(In reply to Ryan Feeley [:rfeeley] from comment #13) > For Windows, Mac, Android this will look like: > > |Firefox| Tab received > | icon | breckenreid.com/portraits/u7th… > > > For iOS this will look like: > > |Firefox| Firefox > | icon | Tab received: breckenreid.com/por… > > This keeps it simple, consistent across platforms, and avoids the complexity > of degrading gracefully when device name and/or page title are not available. > > Make sense? Makes sense to me. Though, we've had localization (character length) issues with "Tab receivied:". Might I suggest consider dropping it altogether?

If we remove "Tab received", there won't be much context around the notification. It would look like this (which seems pretty unclear if you see that on a lock screen): >|Firefox| breckenreid.com/portraits/u7th… >| icon |

> Makes sense to me. Though, we've had localization (character length) issues > with "Tab receivied:". Might I suggest consider dropping it altogether? I would agree if the only notification that Firefox delivered was related to sent tabs, but as more and more services take advantage of notifications, the context is necessary. Other possible labels that are shorter in English at least: * New tab: www.breckenreid.com/page… * New: www.breckenreid.com/pages/po… * Tab: www.breckenreid.com/pages/po… * Incoming: www.breckenreid.com/pag… Or an emoji? That would be really cool.

Some possibilities: |Firefox| Firefox | icon |

Oh yeah, Bugzilla can't handle emojis.

(In reply to Alex Davis [:adavis] from comment #16) > If we remove "Tab received", there won't be much context around the > notification. > > It would look like this (which seems pretty unclear if you see that on a > lock screen): > > >|Firefox| breckenreid.com/portraits/u7th… > >| icon | This is a very deliberate action. I think there's actually already a lot of context around the notification. I also wonder how much a user needs to know this tab is different (something they sent to themselves), vs/ what pressing this notification will actually open (which URL, is it something they want to look at right now?, is it private? do they have the precious mb left?) For example, in German (via google translate, so maybe not terribly accurate) "tab received" = "registerkarte erhalten" Perhaps Michelle has some input here though. (NI'ing her) (In reply to Ryan Feeley [:rfeeley] from comment #19) > Created attachment 8800169 [details] > emojis.png > > Oh yeah, Bugzilla can't handle emojis. I love emojis! But I think we should keep thinking about that as a separate issue so as not to increase scope.

Hi - thought I replied to this last week. I agree with Anthony that a user probably needs the URL more than they need to be reminded that this is a tab they sent themselves. I would lose the additional characters for New Tab to prioritize the URL, if that is our only option. Tagging on to the emoji discussion: Is there a different icon that can accompany the notification, or are we bound to one Firefox icon for all notifications? Could we have an icon that blends the FF logo and the + of a new tab? Or, if we can't do that, rather than an emoji, can we send along an image of the Firefox tab preceding the URL?

> I think there's actually already a lot of context around the notification. From desktop to mobile, you are probably right. It will be instantaneous, and it's likely that the mobile device will be nearby. But imagine the scenario where a user is commuting, and sends a few tabs to a desktop computer. Hours later, or even after the weekend, they open their computer and get many notifications from many different applications. Several may even be coming from Firefox for other things (site subscriptions). > For example, in German (via google translate, so maybe not terribly accurate) > > "tab received" = "registerkarte erhalten" Germans use "Tab", but I get your point: on iOS in particular, it eats up a lot of the visible area. I think you're coming to town, so let's hash out a plan. I think we can do one that degrades gracefully for iOS, but has more features for desktop Firefox.

With regards to Windows notifications: yeah, that sounds good! We are currently doing our own notifications on Windows (mostly because only Windows 10 has decent system notifications and we still have many users on Windows 7). The spec for the notifications is here: https://mozilla.invisionapp.com/share/VC6ZVT1UG#/119857973_Notification_Sizing_2 I'd suggest adding the device that the tab has been sent from in the gray text at the bottom (if we have that information).

Updated for iOS 10

A reminder that we really want "send tab to device" to ride the trains this cycle, and this bug is the only remaining blocker. Given this will impact strings, we can't request uplift, so it will need to land by the end of next week to make 52.

rfeeley: Since time seems to be running out, is there something we can do as a phase 1 by EOW while we work on perfect for train 53?

I met with JR Conlin yesterday to discuss the capabilities of Push. We can, and should, send as much information as possible, and degrade gracefully per platform. It also looks like iOS can support notification title, so we needn't use the colon treatment there (cough, cough). For Phase 1, I am suggesting we include the following when the device name is not known: |Firefox| Tab received | icon | breckenreid.com/portraits/u7th… And if we do know the device name, we show this: |Firefox| Tab from Ryan Feeley’s iPhone… | icon | breckenreid.com/portraits/u7th… JR pointed out that it's important to show the device name as it mitigates the problem of websites disguising notifications as sent tabs. Make sense?

(In reply to Ryan Feeley [:rfeeley] from comment #27) > JR pointed out that it's important to show the device name as it mitigates > the problem of websites disguising notifications as sent tabs. Note that web notifications on Desktop and Android have a "via site.com" subtitle to help mitigate this. Desktop also has an action button to disable notifications from that site.

(In reply to Ryan Feeley [:rfeeley] from comment #27) > For Phase 1, I am suggesting we include the following when the device name > is not known: > > |Firefox| Tab received > | icon | breckenreid.com/portraits/u7th… <b>Tab received</b> |Firefox| breckenreid.com/portraits/u7th/ | icon | foo/bar.html ie, note how "Tab Received" looks like a heading, in bold, above the logo. The "body" of the notification wraps, and on my machine can handle 4 lines before ellipsis are added, and a quick look shows that we can't prevent that wrapping, and we probably also can't calculate where that wrapping would happen and truncate the URL ourselves (although it does seem to wrap on slash characters, so we've got that going for us, which is nice) > And if we do know the device name, we show this: > |Firefox| Tab from Ryan Feeley’s iPhone… > | icon | breckenreid.com/portraits/u7th… ie, in this case, the "Tab from Ryan Feeley’s iPhone" string will be the title (ie, all in bold above the logo) Note also that these URLs can be extremely long. I suspect we might want to stop the query and fragment portions of the URL (ie, anything after a "?" or "#") - Ryan, does that sound right? Even then, some URLs remain long - a quick look through my history found a 248 character URL without any "?" or "#" - that is what is shown in the attachment - Ryan, does that look OK to you? I've attached what this long URL would look like with Ryan's proposal.

(In reply to Mark Hammond [:markh] from comment #29) > > ie, note how "Tab Received" looks like a heading, in bold, above the logo. > The "body" of the notification wraps, and on my machine can handle 4 lines > before ellipsis are added Oh jeez, that's hyooge. Well, I think it's okay for our first release. I thought our Windows notifications also said "via site.com" as Kit mentioned above. I don't see it on this Windows one. > Note also that these URLs can be extremely long. I suspect we might want to > stop the query and fragment portions of the URL (ie, anything after a "?" or > "#") - Ryan, does that sound right? Sure, that seems fine, although JR said we have over 1K for the whole notification, which is a pretty long URL, no? > Even then, some URLs remain long - a quick look through my history found a > 248 character URL without any "?" or "#" - that is what is shown in the > attachment - Ryan, does that look OK to you? Yes, I think this is good for now.

What should it say for multiple tabs received? Right now we say `{count} tabs have arrived from {deviceName}` for the body, and `Multiple tabs received` for the title. There's also the cases where it came from multiple devices, in which case we say `{count} tabs have arrived from your connected devices.` for the body.

(In reply to Ryan Feeley [:rfeeley] from comment #30) > Oh jeez, that's hyooge. Well, I think it's okay for our first release. I > thought our Windows notifications also said "via site.com" as Kit mentioned > above. I don't see it on this Windows one. … > Sure, that seems fine, although JR said we have over 1K for the whole > notification, which is a pretty long URL, no? Remember that we're talking about Send Tab here, not web push. I'm not sure what the URL length limitations are for sent tabs, but you can probably assume something like 65,000 characters. That will comfortably fit within the 256KB we have for a Sync client record.

(In reply to Thom Chiovoloni [:tcsc] from comment #31) > What should it say for multiple tabs received? Right now we say `{count} > tabs have arrived from {deviceName}` for the body, and `Multiple tabs > received` for the title. > > There's also the cases where it came from multiple devices, in which case we > say `{count} tabs have arrived from your connected devices.` for the body. If the device name is missing in this case, I think we should say: {count} tabs have arrived. Hopefully Push will mitigate this from happening as much (notifications will come one at a time in more contexts).

> Remember that we're talking about Send Tab here, not web push. I'm not sure > what the URL length limitations are for sent tabs, but you can probably > assume something like 65,000 characters. That will comfortably fit within > the 256KB we have for a Sync client record. Thanks for the reminder. Yes, the 'via site' is only for Push notification. These are desktop notifications triggered by Push, not actually Push notifications (IIUC).

:markh, let me know if I need to do anything else as part of this. :rfeeley, these are screenshots of the notifications in the patch http://imgur.com/a/S6Gvr (imgur album because I didn't want to upload 5 images to bugzilla, or bother with combining them in an image editor -- sorry) Let me know if these are what you had in mind.

Great work Thom! Thanks for making creative use of imgur. It's a shame bugzilla isn't better at this.

Updated following comments on IRC -- removed trailing periods from strings and we now follow the URL bar's logic for whether or not to show the url scheme (e.g. hide http://, show all others)

Comment on attachment 8803414 [details] Bug 1305737 - String changes to handle the cases where we don't have the device name for a sent tab. https://reviewboard.mozilla.org/r/87686/#review86884 Looks great, thanks! ::: browser/components/nsBrowserGlue.js:2353 (Diff revision 2) > > let title, body; > const deviceName = Weave.Service.clientsEngine.getClientName(URIs[0].clientId); > const bundle = Services.strings.createBundle("chrome://browser/locale/accounts.properties"); > if (URIs.length == 1) { > + if (deviceName) { Can you please add a comment along the lines of "Due to bug 1305895, tabs from iOS may not have device information, so we have separate strings to handle that case. We can probably remove this once that bug has hit iOS release" or similar.

Pushed by tchiovoloni@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c32122f59be5 String changes to handle the cases where we don't have the device name for a sent tab. r=markh