1000131 - Standalone UI for link clickers needs expired URLs notification.

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect, P1)

Comment 1

[:shell escalante]

validate verbiage - "link has expired" or "you may want to ask user to resend" or something to send like that.

Comment 2

[Darrin Henein [:darrin]]

I'm leaning towards something more generic, like "This URL is no longer available" or "Oops! There's nothing here!"

This page will show up after expiration, revocation, wrong url/typo (no call ever existed there), etc.

Thoughts?

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

More generic seems friendlier.  Perhaps adding some verbiage guiding the user about what to do next would be nice?  e.g. "Try checking with the person who gave you this link to see if they have another"

Dan

Comment 4

[Darrin Henein [:darrin]]

The UI is simple (https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#start-call-unavailable) we just need to decide on the string(s).

Something like "This URL is unavailable" seems most generic (handles all cases best). I like Dan's suggestion but it seems a bit verbose... could we have a "Get Link" button here that just opens the panel and selects the new link text box maybe?

Comment 5

[Romain Testard [:RT]]

This bug is for the standalone UI for link clickers whereas the UI here is for the client UI. Can we have standalone client UI too please?

Not sure I understand the question "could we have a "Get Link" button here that just opens the panel and selects the new link text box maybe?" This UI is for link clickers (i.e not someone who generated the URL) on the Web clicker UI. The Web clicker UI user can not generate URLs.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Yeah, there are no panels in the standlone UI, and that context doesn't know what channel the link came from.  You're right that my suggested text was verbose.  Maybe "Oops, there's nothing here -- try asking for a new link"?  It's sort of opaque, but I'm not sure how to do better.  

I like the "Oops..." wording you suggested, because it feels like it moves Firefox in the more playful, humane direction described by the design values doc you sent out some time ago.

Comment 7

[Darrin Henein [:darrin]]

My bad, was thinking of the desktop client UI. Agreed, this will be simple and will be included in the spec for the standalone app UI.

Comment 8

[Adam Roach [:abr]]

One quick comment on this -- we aren't going to be able to tell the difference between an expired URL and a URL that is otherwise invalid (e.g., was damaged during cut-and-paste or was modified by the user). The UX should take this into account.

Comment 9

[:shell escalante]

UI: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired

Comment 10

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

(In reply to sescalante from comment #9)
> UI: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired

I don't entirely grasp what to do with the "Download Firefox to make free audio and video calls!" invite and associated "Get Firefox" button; what if the user is already using Firefox, should I hide these?

Also, I'm wondering if I should match the new design in this very bug, or if it should be done in a separated, dedicated bug? The thing is that applying new styles matching this new screen is likely to break other parts, so maybe proceeding with the redesign as one step could be easier to review, and land. Thoughts?

Comment 11

[Romain Testard [:RT]]

(In reply to Nicolas Perriault (:NiKo`) from comment #10)
> (In reply to sescalante from comment #9)
> > UI: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired
> 
> I don't entirely grasp what to do with the "Download Firefox to make free
> audio and video calls!" invite and associated "Get Firefox" button; what if
> the user is already using Firefox, should I hide these?
> 
Yes I agree, the message prompting the user to download Firefox and the "download" button should be hidden in case the user is on Firefox.


> Also, I'm wondering if I should match the new design in this very bug, or if
> it should be done in a separated, dedicated bug? The thing is that applying
> new styles matching this new screen is likely to break other parts, so maybe
> proceeding with the redesign as one step could be easier to review, and
> land. Thoughts?

Comment 12

[Mark Banner (:standard8)]

(In reply to Nicolas Perriault (:NiKo`) from comment #10)
> Also, I'm wondering if I should match the new design in this very bug, or if
> it should be done in a separated, dedicated bug? The thing is that applying
> new styles matching this new screen is likely to break other parts, so maybe
> proceeding with the redesign as one step could be easier to review, and
> land. Thoughts?

Its hard to know how much that would break, without digging through the css. Maybe if you do it as two separate patches - one for the changes in this bug, one for the redesign, and then maybe that will be easier to see as it moves on, how much it would really break.

Comment 13

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

So reading the new loop-server code (master and 0.9.0, which is roughly MVP if I'm correct), the format used for errors in served JSON responses has changed recently: https://github.com/mozilla-services/loop-server/blob/77dde7ee23e02bedc402f4212cbb9b3bf8a444b9/loop/utils.js#L9-L29

The Loop desktop client in nightly is still relying on the old format, which is still deployed on production (https://loop.services.mozilla.com/ declares using a 0.5.0). 

I need to update the standalone client code to match the new error format to address this bug, but be aware that it needs to land along with deploying the new loop-server error format to production; and right now, I don't know if we have a plan for that. 

Putting :abr and :tarek as needinfo and will update the related thread on dev-media.

Comment 14

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Wondering if bug 1000131 should be a blocker for this one.

Comment 15

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

I meant bug 1025792, obviously.

Comment 16

[Adam Roach [:abr]]

It seems to be that the server team is deploying both components, so I think we can leave it up to them to ensure that they go live at the same time, so long as we've made the corresponding client changes in time.

Tarek: does that make sense?

Comment 17

[Tarek Ziadé (:tarek)]

If by client you mean the code that is in loop-client, yes this can probably happen. Adding Bob and Benson to have a 100% confirmation from them.

Comment 18

[Tarek Ziadé (:tarek)]

Mark, Niko, can we meet about this tomorrow ? e.g. fixing+tagging loop-client that matches, so it's available for deployment.

Comment 19

[Benson Wong [:mostlygeek]]

OK from discussion w/ Tarek we are going to deploy loop-server 0.10.0 and loop-client 0.1.1 to prod at the same time.

Comment 20

[Bob Micheletto [:bobm]]

(In reply to Ben Wong [:mostlygeek] from comment #19)
> OK from discussion w/ Tarek we are going to deploy loop-server 0.10.0 and
> loop-client 0.1.1 to prod at the same time.

Clearing my needinfo.

Comment 21

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: Part 1: fixed server json error handling, expired urls notification

This is the first part of the patch:

- fixed loop-server new JSON error format handling
- new `session:expired` ConversationModel event
- reactified webapp.js, where a new CallUrlExpiredView component has been added
- as loop-server sends 404 - Not Found and INVALID_TOKEN for expired urls, updated notification message to "This call URL is no longer available and has probably expired." (adding :darrin for feedback)

WiP branch matching that patch has been pushed to my gecko-dev fork: bug-1000131-expired-urls

Part 2 will care of webdesign updates.

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8458594 [details] [diff] [review]
Part 1: fixed server json error handling, expired urls notification

r=dmose, once the comments we discussed over video are addressed

Comment 23

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: Part 1: fixed server json error handling, expired urls notification - rev2

Addressed comments.

Comment 24

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8459146 [details] [diff] [review]
Part 1: fixed server json error handling, expired urls notification - rev2

Review of attachment 8459146 [details] [diff] [review]:
-----------------------------------------------------------------

I found a problem, unfortunately, which needs some work, so I need to r- until this gets fixed.

::: browser/components/loop/content/shared/js/models.js
@@ +214,5 @@
> +     *
> +     * @param  {Error} err Error object.
> +     */
> +    _handleServerError: function(err) {
> +      var jsonErr = err.jsonErr || {};

The problem with this initialization is that if we hit the {} clause, the switch statement will throw an exception trying to access an undefined property.

This clause can actually hit if the catch clause in standaloneClient.js:requestCallInfo's req.done gets invoked.  Additionally, it will also be invoked to handle errors from callbacks from requestCall{s,}Info from client.js, and those functions have a bunch of cases that don't inject jsonErr.

So I think we probably want to declare that this method supports handling Error objects without .jsonErr properties, update the docs, write a test for that, and make it pass.

Also, boy do we want integration testing.  :-)

Comment 25

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: 0001-Bug-1000131-Expired-Loop-call-url-notification-part1-rev3.patch

Addressed latest comments.

Comment 26

[Romain Testard [:RT]]

(In reply to Romain Testard [:RT] from comment #11)
> (In reply to Nicolas Perriault (:NiKo`) from comment #10)
> > (In reply to sescalante from comment #9)
> > > UI: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired
> > 
> > I don't entirely grasp what to do with the "Download Firefox to make free
> > audio and video calls!" invite and associated "Get Firefox" button; what if
> > the user is already using Firefox, should I hide these?
> > 
> Yes I agree, the message prompting the user to download Firefox and the
> "download" button should be hidden in case the user is on Firefox.
> 
Please note the amended design:
Non Firefox link clicker: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired
Firefox link clicker: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx

Comment 27

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

(In reply to Romain Testard [:RT] from comment #26)
> Please note the amended design:
> Non Firefox link clicker:
> https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired
> Firefox link clicker:
> https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx

Thanks. Now I think about it, shouldn't we use the Hello logo instead of the Firefox one for the FF version? Maybe even in both cases actually.

Comment 28

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Comment on attachment 8459356 [details] [diff] [review]
0001-Bug-1000131-Expired-Loop-call-url-notification-part1-rev3.patch

This patch is broken. I need to find a better strategy for dealing with server error identifiers.

Comment 29

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: 0001-Bug-1000131-Expired-Loop-call-url-notification-part1-rev4.patch

Fixed previous patch with a simpler approach, attaching only the `errno` code to the Error object.

What we really want in the future is a typed Error object for server errors, eg. ServerError, which should be shared across all clients. Though this is probably out of the scope of this bug, hence why I'll create a dedicated bug once this patch is validated.

Comment 30

[Romain Testard [:RT]]

(In reply to Nicolas Perriault (:NiKo`) from comment #27)
> (In reply to Romain Testard [:RT] from comment #26)
> > Please note the amended design:
> > Non Firefox link clicker:
> > https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired
> > Firefox link clicker:
> > https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx
> 
> Thanks. Now I think about it, shouldn't we use the Hello logo instead of the
> Firefox one for the FF version? Maybe even in both cases actually.

I have questions regarding logos pending with Arcadio (a branding discussion really). I also question if we should use the Mozilla logo at all given it may cause confusion for users who will know the product as Firefox Hello.
I needInfo Arcadio who we'll be discussing this with tonight so hoping to have an answer later today.

Comment 31

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: Expired Loop call url notification, part1 rev5

Comment 32

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: Expired Loop call url notification, r=dmose

Comment 33

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: [checked-in] Expired Loop call url notification, r=dmose

Comment 34

[Dan Mosedale (:dmosedale, :dmose)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/18ff00a31dc5

Comment 35

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/18ff00a31dc5

Comment 36

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

(In reply to Romain Testard [:RT] from comment #30)
> I needInfo Arcadio who we'll be discussing this with tonight so hoping to
> have an answer later today.

Any news? Also, provided mockups (https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired) uses an image for the Hello Logo, and a retina version isn't provided. So I'd like to know:

- if any branding issue so this is blocked,
- or if this is fine, who should I ask a retina version for — :darrin being currently on PTO.

Comment 37

[:shell escalante]

decision to use Loop in aurora - and Hello in Fx34.  won't go to beta.

Comment 38

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: Part 2: updating expired url view to match the styles in the mockups

This is the second part of the patch, bringing styling to the view previously landed. Fixed a bunch of broken common styles and fixed the readme.html file accordingly.

Comment 39

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: Part 2: screen capture for UX review

Screenshot attached for UX review. Link to the source mockup is https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx

Comment 40

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8460320 [details] [diff] [review]
Part 2: updating expired url view to match the styles in the mockups

r=dmose with the tweaks suggested in the review at <https://github.com/n1k0/gecko-dev/commit/37d37ce9605807b7e8dd31f7d40030717c2ce538#diff-f67d8232f05108a1c64b104ae33eca6bR170>.

Comment 41

[Sevaan Franks [:sevaan]]

(In reply to Nicolas Perriault (:NiKo`) from comment #36)

> Also, provided mockups
> (https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired) uses
> an image for the Hello Logo, and a retina version isn't provided. So I'd
> like to know:
> 
> - if any branding issue so this is blocked,
> - or if this is fine, who should I ask a retina version for — :darrin being
> currently on PTO.

mmaslaney  should be able to provide a retina version once he receives the OK from branding.

Comment 42

[Sevaan Franks [:sevaan]]

Comment on attachment 8460324 [details]
Part 2: screen capture for UX review

Hi NiKo, that's looking good.

The spec, however, has a max-width of 400px and the text where it says "Oops" and "The URL is no longer available" are darker in the spec.

Oops should be #666 and the URL string should be #AAA.

Also, missing the logo, but you mentioned why above.

Comment 43

[Sevaan Franks [:sevaan]]

Copy question for Matej...

:dmose brought to my attention the string underneath the "Oops" box which says "Download Firefox to make free audio and video calls!"

He brought up the valid point that Firefox Hello will not be in wide versions of Firefox for a bit, so the string is not entirely accurate as this stage (even misleading).

a) Is this a concern?
b) If so, could you provide an alternate string to entice users to download Firefox (not necessarily Loop related...this could just be a promotional spot)?

Here is the spec for the page I am referring to: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired

Comment 44

[Matej Novak [:matej]]

Can I get a little more info about when and where this will show up? If it's an error message for Firefox Hello, wouldn't it already be available and in use? In that case the string wouldn't be inaccurate, would it?

I'm actually more concerned about the exclamation mark after Firefox Hello at the top. Is that deliberate?

Thanks.

Comment 45

[Sevaan Franks [:sevaan]]

(In reply to Matej Novak [:matej] from comment #44)
> Can I get a little more info about when and where this will show up? If it's
> an error message for Firefox Hello, wouldn't it already be available and in
> use? In that case the string wouldn't be inaccurate, would it?
> 
> I'm actually more concerned about the exclamation mark after Firefox Hello
> at the top. Is that deliberate?
> 
> Thanks.

Hey Matej,

If a call link is no longer valid, users of Firefox see this page which basically tells them the URL is unavailable: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx

For users using other browsers, this is a good spot to entice them to download Firefox, so at the footer of the page we have the aforementioned string and a button which takes the user to the download Firefox page: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired

Hello is only available in Nightly/Aurora and not our release version of Firefox...so if someone sees that ad when clicking on a link through Chrome, they may think "Oh, I can make calls too!" and download Firefox only to find the functionality is not available.

So until Hello is available in all versions, maybe there is some other way we can entice users of other browsers to give Firefox a try.

Comment 46

[Sevaan Franks [:sevaan]]

(In reply to Matej Novak [:matej] from comment #44)
 
> I'm actually more concerned about the exclamation mark after Firefox Hello
> at the top. Is that deliberate?


As for the exclamation mark, I am not sure. Arcadio Lainez (alainez) has been handling the branding and might be able to chime in on whether it's "Firefox Hello" or "Firefox Hello!"

Comment 47

[Matej Novak [:matej]]

Thanks for the clarification. I love the idea of getting people to download Firefox from this page with the hook of being able to make free calls. It's a clear, easy fit.

I worry about doing it before Hello is available in all versions, though. Telling them the link is unavailable, then asking them to download the browser for an unrelated reason feels like a bait and switch. It may not send the right message or give them the best first impression of Firefox.

Can we remove it until Hello lands in GA?

As for the exclamation mark, that definitely isn't right. The wordmark lockup doesn't look right either (I don't think it's the right font). If formatted that way, it should be an image and use Meta. Otherwise it should be live text, but then not using different font weights for Firefox and Hello.

I'm adding John Slater who can comment further on the branding.

Comment 48

[John Slater]

(In reply to Matej Novak [:matej] from comment #47)
> As for the exclamation mark, that definitely isn't right. The wordmark
> lockup doesn't look right either (I don't think it's the right font). If
> formatted that way, it should be an image and use Meta. Otherwise it should
> be live text, but then not using different font weights for Firefox and
> Hello.

Thanks Matej. I definitely agree with the above comments...we shouldn't be using the exclamation point with this, and the wordmark formatting looks off. There are wordmark guidelines at the bottom of this page that will help: https://www.mozilla.org/en-US/styleguide/communications/typefaces/. Alternately, my team can put something together if we need it.

Beyond that, if there are branding decisions being made about how we represent Hello in the product (wordmark or no wordmark, etc) then I'd like Matej and I to be in the loop on those.

Thanks!

Comment 49

[Romain Testard [:RT]]

(In reply to Sevaan Franks [:sevaan] from comment #46)
> (In reply to Matej Novak [:matej] from comment #44)
>  
> > I'm actually more concerned about the exclamation mark after Firefox Hello
> > at the top. Is that deliberate?
> 
> 
> As for the exclamation mark, I am not sure. Arcadio Lainez (alainez) has
> been handling the branding and might be able to chime in on whether it's
> "Firefox Hello" or "Firefox Hello!"

Please note that as per discussion with Arcadio yesterday we should not be using the "Firefox Hello" brand for now (likely we'll use it when we get to beta). For Nightly and Aurora we should replace "Hello" by "WebRTC" wherever "Hello" appears in the UX and also use the Firefox logo instead of the speech bubble for now.

Comment 50

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: Part 2: updating expired url view to match the styles in the mockups (rev2)

Updated patch with :dmose and :sevaan comments addressed. No app logo is part of this patch, so there will probably be a Part 3 (or another bug, maybe)… but I'd really like this to land because it really improves the current app look and feel :)

Comment 51

[Matej Novak [:matej]]

(In reply to Romain Testard [:RT] from comment #49)
> (In reply to Sevaan Franks [:sevaan] from comment #46)
> > (In reply to Matej Novak [:matej] from comment #44)
> >  
> > > I'm actually more concerned about the exclamation mark after Firefox Hello
> > > at the top. Is that deliberate?
> > 
> > 
> > As for the exclamation mark, I am not sure. Arcadio Lainez (alainez) has
> > been handling the branding and might be able to chime in on whether it's
> > "Firefox Hello" or "Firefox Hello!"
> 
> Please note that as per discussion with Arcadio yesterday we should not be
> using the "Firefox Hello" brand for now (likely we'll use it when we get to
> beta). For Nightly and Aurora we should replace "Hello" by "WebRTC" wherever
> "Hello" appears in the UX and also use the Firefox logo instead of the
> speech bubble for now.

In that case "Firefox WebRTC" should all be live text and in the same font weight so it doesn't look like a wordmark.

Thanks.

Comment 52

[Sevaan Franks [:sevaan]]

Regarding the string about making free calls...

(In reply to Matej Novak [:matej] from comment #47) 
> Can we remove it until Hello lands in GA?

Yes. Let's remove the string from that page for now, however, we'll keep the "Get Firefox" button.

Comment 53

[Sevaan Franks [:sevaan]]

Regarding the string about making free calls...

(In reply to Matej Novak [:matej] from comment #47) 
> Can we remove it until Hello lands in GA?

Yes. Let's remove the string from that page for now but we'll still keep the "Get Firefox" button.

Comment 54

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8460806 [details] [diff] [review]
Part 2: updating expired url view to match the styles in the mockups (rev2)

Review of attachment 8460806 [details] [diff] [review]:
-----------------------------------------------------------------

r=dmose, with the changes requested by Sevaan and Matej.

Comment 55

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: (Part 2): Loop expired call url view styling.

Refreshing patch for testing moz-git-tools git-bz command.

Comment 56

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: (Part 2): Loop expired call url view styling, r=dmose.

Rebased patch against latest master.

Comment 57

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Attachment: (Part 2): Loop expired call url view styling

Rebased patch against real upstream master (sorry for the noise).

Comment 58

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: (Part 2): Loop expired call url view styling, v3, rebased again

Comment 59

[Dan Mosedale (:dmosedale, :dmose)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e566ade6f17e

Comment 60

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e566ade6f17e

Comment 62

[Paul Silaghi, QA [:pauly]]

(In reply to Sevaan Franks [:sevaan] from comment #45)
> If a call link is no longer valid, users of Firefox see this page which
> basically tells them the URL is unavailable:
> https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx
Does https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#start-call-unavailable still stands for other cases?
If not, how can the link-expired be triggered (tested) ?

Comment 63

[Romain Testard [:RT]]

(In reply to Paul Silaghi, QA [:pauly] from comment #62)
> (In reply to Sevaan Franks [:sevaan] from comment #45)
> > If a call link is no longer valid, users of Firefox see this page which
> > basically tells them the URL is unavailable:
> > https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx
> Does
> https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#start-call-
> unavailable still stands for other cases?
> If not, how can the link-expired be triggered (tested) ?

Yes, there was no bug and I just created on to track the implementation of it: https://bugzilla.mozilla.org/show_bug.cgi?id=1047399

Comment 64

[Mark Banner (:standard8)]

This landed without the branding, which will be handled by a different bug. Hence, removing the need info request from comment 46.

Comment 65

[u279076]

(In reply to Romain Testard [:RT] from comment #63)
> (In reply to Paul Silaghi, QA [:pauly] from comment #62)
> > (In reply to Sevaan Franks [:sevaan] from comment #45)
> > > If a call link is no longer valid, users of Firefox see this page which
> > > basically tells them the URL is unavailable:
> > > https://people.mozilla.org/~dhenein/labs/loop-link-spec/#link-expired-ffx
> > Does
> > https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#start-call-
> > unavailable still stands for other cases?
> > If not, how can the link-expired be triggered (tested) ?
> 
> Yes, there was no bug and I just created on to track the implementation of
> it: https://bugzilla.mozilla.org/show_bug.cgi?id=1047399

Adding dependency since this was duped. Let's move follow-up testing to bug 1000202.