Are the options for native.showPopup( "social", options ) totally redundant when posting to Facebook?

Solar2D General Questions/Discussion
#1

Looking at the docs for native social popups, it looks like this is a perfectly valid call (assuming the popup is available):

local options = { service = "facebook", message = "hi there!", listener = listener, image = { { filename = "world.jpg", baseDir = system.ResourceDirectory }, }, url = { "http://docs.coronalabs.com", } } native.showPopup("social", options)

The url property always seemed a bit…useless if I’m honest. It just added the url string to the main popup message field, so was no different to just appending the string to one supplied to the “message” property.

However we’ve hit upon a problem, perhaps someone can enlighten us if we are doing this incorrectly.

We were supplying a url which leads to our app on the appstores, but have received an email from Facebook telling us that this is not allowed:

We’ve noticed that your app is pre-filling content via Apple’s share dialog, which violates Platform Policy 2.3: Ensure that all content in the user message parameter is entered by the user. Don’t pre-fill. This includes posts, messages, comments, and captions. 

 

I had previously looked into this and am 99% sure I had found information saying that this was ok (which I cannot find now).

 

At any rate, it means that both the “message” and “url” properties are totally redundant, as we cannot pass any info to them.

 

Am I misreading this somehow, or are those properties not useful for Facebook posts? I’m aware that they can be used for Twitter etc. However I’m concerned that it’s very easy to assume that these fields can be used for Facebook as well, when it violates Facebook’s terms.

 

#2

Hi @corona1634,

For Facebook, I believe the “url” field shouldn’t be in there, but “message” should. However, Facebook routinely changes its policies on what may or may not be allowed, so I think you’ll need to test it and see if they continue to notify you.

I assume you’ve read through this brief tutorial?

http://coronalabs.com/blog/2013/08/06/introducing-the-social-plugin-ios/

Take care,

Brent

#3

I’ve read the tutorial, but there’s still nothing that covers my main point which is Facebook’s terms and conditions:

We’ve noticed that your app is pre-filling content via Apple’s share dialog, which violates Platform Policy 2.3: Ensure that all content in the user message parameter is entered by the user. Don’t pre-fill. This includes posts, messages, comments, and captions. 

If you supply any text at all to the message field, the popup will be prefilled. This violates Facebook terms and means that when “facebook” is given as the service name, the message field shouldn’t be a valid field. I don’t see any way that you could supply an string other than “” to it and call the function without violating Facebook’s terms.  

It seems like a very minor point, but as I say we’ve had an email from Facebook asking us to rectify this issue and I suspect other devs could run into the same problem (especially if they look into any kind of Facebook promotion).

#4

the “no pre-fill” rule has been in their terms since circa 2011, but they’ve apparently only started actively enforcing it this year (during the new app review process)

the only way your app should be populating text values is if you’ve gathered them “elsewhere” from the user via a custom ui – and if so you must not change/alter/amend from exactly what the user typed.  if you’re doing that, you may want to add a testing note during app review to clarify for reviewer how/where you’re gathering the user-entered values so they can properly test (otherwise they might still fail you if it seems sufficiently “disconnected” and it’s not obvious where the prefill text came from)

since you say you “received an email” then you probably created your fb app prior to the new review process.  they’ve since “noticed” it (rumor is they’ve got auto-spam detectors checking up on older apps) and are informing you, and will eventually disable your app if not resolved.  if it were a NEW review submission, you’d instead get a message in your dev console that it failed review (with similar language) so never enabled.  same effect eventually either way, and must stop the prefill to fix.

hth

#5

Hi @corona1634,

For Facebook, I believe the “url” field shouldn’t be in there, but “message” should. However, Facebook routinely changes its policies on what may or may not be allowed, so I think you’ll need to test it and see if they continue to notify you.

I assume you’ve read through this brief tutorial?

http://coronalabs.com/blog/2013/08/06/introducing-the-social-plugin-ios/

Take care,

Brent

#6

I’ve read the tutorial, but there’s still nothing that covers my main point which is Facebook’s terms and conditions:

We’ve noticed that your app is pre-filling content via Apple’s share dialog, which violates Platform Policy 2.3: Ensure that all content in the user message parameter is entered by the user. Don’t pre-fill. This includes posts, messages, comments, and captions. 

If you supply any text at all to the message field, the popup will be prefilled. This violates Facebook terms and means that when “facebook” is given as the service name, the message field shouldn’t be a valid field. I don’t see any way that you could supply an string other than “” to it and call the function without violating Facebook’s terms.  

It seems like a very minor point, but as I say we’ve had an email from Facebook asking us to rectify this issue and I suspect other devs could run into the same problem (especially if they look into any kind of Facebook promotion).

#7

the “no pre-fill” rule has been in their terms since circa 2011, but they’ve apparently only started actively enforcing it this year (during the new app review process)

the only way your app should be populating text values is if you’ve gathered them “elsewhere” from the user via a custom ui – and if so you must not change/alter/amend from exactly what the user typed.  if you’re doing that, you may want to add a testing note during app review to clarify for reviewer how/where you’re gathering the user-entered values so they can properly test (otherwise they might still fail you if it seems sufficiently “disconnected” and it’s not obvious where the prefill text came from)

since you say you “received an email” then you probably created your fb app prior to the new review process.  they’ve since “noticed” it (rumor is they’ve got auto-spam detectors checking up on older apps) and are informing you, and will eventually disable your app if not resolved.  if it were a NEW review submission, you’d instead get a message in your dev console that it failed review (with similar language) so never enabled.  same effect eventually either way, and must stop the prefill to fix.

hth