1107866 - [Loop] Sharing the url with pinterest cause the user can't use loop until restarting it

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect)

Description

[mbarone]

Attachment: 2014-12-05-12-24-54.png

Device: Fire E (Build Fire_E_user_SW_03001)
Loop: 4212078

STR
1. Use pinterest to share a loop url with someone

ACTUAL RESULT
The user can't close the pinterest window. Also if you introduce the valid credential, when the user open loop app, the pinterest content is displayed. In other words, pinterest window is in foreground until the user restart loop app

Comment 1

[mbarone]

Attachment: 2014-12-05-12-30-22.png

Comment 2

[Beatriz Rodríguez [:brg]]

Mike, could you please check this issue?

Comment 3

[Beatriz Rodríguez [:brg]]

Scenario for testing: you need to install Loop and Pinterest applications.

The STR to be more clear is:
- Open loop
- Register using FxAccounts or Mobile phone number
- Select a contact in your phonebook(without the service) to communicate
- When the option to share the link is listed, select: Other,
- Then choose: Pinterest

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Pinterest is reacting correctly; we're given a URL from which to create a Pin, but there aren't any Pinnable images at that URL.

To better control what content we scrape from the given URL, please use the following meta tags:

<meta property="pin:url" content="http://yourdomain.com/yourpage.html" />
<meta property="pin:description" content="This is the description you'd like us to pin from this page." />
<meta property="pin:media" content="http://cdn.yourdomain.com/yourimage.png" />

Comment 5

[Daniel Coloma:dcoloma]

(In reply to Mike Beltzner [:beltzner, not reading bugmail] from comment #4)
> Pinterest is reacting correctly; we're given a URL from which to create a
> Pin, but there aren't any Pinnable images at that URL.
> 
> To better control what content we scrape from the given URL, please use the
> following meta tags:
> 
> <meta property="pin:url" content="http://yourdomain.com/yourpage.html" />
> <meta property="pin:description" content="This is the description you'd like
> us to pin from this page." />
> <meta property="pin:media" content="http://cdn.yourdomain.com/yourimage.png"
> />

I don't think the app is doing what it's explictly declaring in the manifest. In the manifest, it says it supports the share activity for URLs:

"activities": {
  "share": {
    "filters": {
       "type": ["url"]
    },
    "disposition": "inline",
    "href": "/index.html?activity"
  }
}

When any app, willing to share any URL asks the system to handle the "share URL" activity, pinterest is going to be listed, as it has explictly stated in the manifest that it can handle any URL, which does not seem to be the case based on comment 4. Based on current behaviour, I think the activity Pinterest handle should be called "pin" rather than "share" as this would avoid any collision.

Furthermore, it seems that after detecting that there is nothing "pinable" the error callback it's not called but the success callback. The right behaviour should be closing the window and invoking the error callback if there is nothing pinnable, in the same way the pinterest app is doing for the cases when the activity parameters are invalid:

if (data.type != 'url') {
  // activity.postError('type not supported');
  window.close();
  return;
}

(this is an excerpt from script.js that is part of the pinterest app in the Marketplace)

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

We'll have to disagree on your definition of what it means to share a URL, I guess. The user can share anything to Pinterest, but if there's no way to represent it on Pinterest, it won't work out for them. No other OS integration has had an issue with Pinterest being a destination for sharing, with the understanding that if there's no Pinnable resource our service will fail.

Your point about the user being stuck at an error message they can't dismiss is well-taken. I'm not sure what we can do about it at this point. We're given a URL from which to Pin, and there's no API I can poke ahead of time to see if there's a Pinnable resource there or not; I have to load the page. I suppose I can have that page emit an event, but at that point the FirefoxOS browser window has already loaded.

If I put a button on it that calls window.close() will that work?

Comment 7

[Daniel Coloma:dcoloma]

(In reply to Mike Beltzner [:beltzner, not reading bugmail] from comment #6)
> We'll have to disagree on your definition of what it means to share a URL, I
> guess. The user can share anything to Pinterest, but if there's no way to
> represent it on Pinterest, it won't work out for them. No other OS
> integration has had an issue with Pinterest being a destination for sharing,
> with the understanding that if there's no Pinnable resource our service will
> fail.
> 

The problem is that the app is not failing gracefully, and allow the user to go back to the invoking app. I have created a simple test app:

https://github.com/dcoloma/share-url-test/tree/master

So you can feel what is the experience of a user that selects Pinterest to share a URL when there is nothing "pinnable" in that URL.

Please compare the behaviour of the Pinterest App with the SMS application that is the other app in FirefoxOS that implements the Share URL activity in an "inline" way. The SMS always allow the user to dismiss the window and go back to the invoking app.

> Your point about the user being stuck at an error message they can't dismiss
> is well-taken. I'm not sure what we can do about it at this point. We're
> given a URL from which to Pin, and there's no API I can poke ahead of time
> to see if there's a Pinnable resource there or not; I have to load the page.
> I suppose I can have that page emit an event, but at that point the
> FirefoxOS browser window has already loaded.
> 
> If I put a button on it that calls window.close() will that work?

I think that is an option, similarly to what SMS app implements. Alternatively, I think you can implement the activity not to be an "inline" one by just removing the line 

"disposition": "inline",

... from your manifest.

In that way, the activity is invoked separately from the invoking app, the e-mail app implements the Share Activity in this way, and hence the close button is not required.

I re-open this bug as having the user stuck at an error message they can't dismiss is clearly something that we should try to fix.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Sorry; the re-WONTFIX was an error (my browser reset the state of all fields to the last time I loaded the page)

I'll give that a whirl.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Removed "disposition": "inline", updated icons and uploaded to Marketplace as v0.3