Facebook 3.1.1 SDK breaks A LOT

haakon · December 30, 2012, 4:39am

Going through our final tests, we discovered that a) you have updated to Facebook SDK 3.1.1 and b) it breaks a lot of stuff.

First of all, the Cancel button in the Dialog is supposed to return the same as the Close button in the Dialog. Now it returns success and true and whatnot:

-- To print the facebook response  
for k, v in pairs(event) do  
 print(k)  
 &nbsp; &nbsp;print(envy)  
end

HITTING THE CANCEL BUTTON:

2012-12-30 13:04:21.680 mindfeud[20930:c07] string :: type
2012-12-30 13:04:21.680 mindfeud[20930:c07] string :: dialog

2012-12-30 13:04:21.681 mindfeud[20930:c07] string :: name
2012-12-30 13:04:21.681 mindfeud[20930:c07] string :: fbconnect

2012-12-30 13:04:21.682 mindfeud[20930:c07] string :: didComplete
2012-12-30 13:04:21.682 mindfeud[20930:c07] boolean :: true

2012-12-30 13:04:21.683 mindfeud[20930:c07] string :: isError
2012-12-30 13:04:21.683 mindfeud[20930:c07] boolean ::

2012-12-30 13:04:21.683 mindfeud[20930:c07] string :: response
2012-12-30 13:04:21.684 mindfeud[20930:c07] string :: fbconnect://success

HITTING THE CLOSE CROSS BUTTON:

2012-12-30 13:05:24.231 mindfeud[20930:c07] string :: type
2012-12-30 13:05:24.231 mindfeud[20930:c07] string :: dialog

2012-12-30 13:05:24.232 mindfeud[20930:c07] string :: name
2012-12-30 13:05:24.232 mindfeud[20930:c07] string :: fbconnect

2012-12-30 13:05:24.232 mindfeud[20930:c07] string :: didComplete
2012-12-30 13:05:24.233 mindfeud[20930:c07] boolean ::

2012-12-30 13:05:24.233 mindfeud[20930:c07] string :: isError
2012-12-30 13:05:24.233 mindfeud[20930:c07] boolean ::

2012-12-30 13:05:24.234 mindfeud[20930:c07] string :: response
2012-12-30 13:05:24.234 mindfeud[20930:c07] string ::

Next out, the facebook session does not seem to survive for more than a few seconds. Maybe it is not being stored at all. After you updated to 3.1.1, authorization must be done every time we open a Dialog, and it must be done 2 times - first time it fails, second time it works. Then, as soon as the dialog is closed in one or another way, and we want to re-open the dialog, then the pattern repeats itself. We’re asking publish_actions for everything in the app from login to getting friends lists to apprequests and wall posts, so it’s not related to the permissions. Either way, this _worked_ before you updated the SDK.

[import]uid: 21746 topic_id: 34416 reply_id: 334416[/import]

rob · December 30, 2012, 10:03am

Can you make a small test case that demonstrates this and file a bug report?

Thanks
Rob
[import]uid: 199310 topic_id: 34416 reply_id: 136792[/import]

haakon · December 30, 2012, 11:52am

Rob,

sorry, I don’t spend time on writing test cases for you guys. I’d expect you to have a proper set of integration tests to catch bugs like this one before you build your product.

However, I took a minute to create a video showing the Close/Cancel bug, using your very own Facebook test project:

http://coronalabs.s3.amazonaws.com/corona_bug.mov

I also confirmed this bug to go back to before 3.3.1 by testing the 990 build, so slap on my own face for blaming the 3.1.1 update. This bug has been here for a long time, and I see in some old code of ours that we’ve worked around it by checking the facebook response for post_id/request_id etc.

I’m still not sure about the session related bug, I’ll do some more testing and put up a video using your test app if I can find the exact way to reproduce it. [import]uid: 21746 topic_id: 34416 reply_id: 136811[/import]

haakon · December 30, 2012, 2:42pm

This is weird. The “session bug” I suggested above is not happening. The problem is with permissions. I have found the steps to reproduce the actual bug with your own sample project.

I made another video showing the 3 changes I made to your main.lua file, and the funky stuff happening when running it.

In short, using the publish_actions permission is what breaks your implementation (you are using the “deprecated” publish_stream permission). publish_actions works in daily build 990 and older, but not in builds after you updated to 3.1.1.

Facebook is very clear about the recommended permission to ask by an app:

Permissions to write actions to a person’s timeline must be requested separately from read permissions. We currently support three publishing permissions: publish_actions, publish_stream, and publish_checkins. Moving forward, we recommend that apps only ask for publish_actions, as this permission encompasses the other two and we want to simplify the model.

If you look at my video, you’ll see an error message in the status text field:

The operation couldn’t be completed. (com.facebook.sdk error 5.)

Video: http://coronalabs.s3.amazonaws.com/corona_bug_2.mov
main.lua: http://coronalabs.s3.amazonaws.com/main.lua

[import]uid: 21746 topic_id: 34416 reply_id: 136828[/import]

rob · December 30, 2012, 10:03am

Can you make a small test case that demonstrates this and file a bug report?

Thanks
Rob
[import]uid: 199310 topic_id: 34416 reply_id: 136792[/import]

haakon · January 3, 2013, 1:31am

Any progress here? It’s not much job for you to verify the bug, I’ve documented it well, and you only need to run your own Facebook project.

This is a complete showstopper for using builds newer than 990. [import]uid: 21746 topic_id: 34416 reply_id: 137194[/import]

haakon · December 30, 2012, 11:52am

Rob,

sorry, I don’t spend time on writing test cases for you guys. I’d expect you to have a proper set of integration tests to catch bugs like this one before you build your product.

However, I took a minute to create a video showing the Close/Cancel bug, using your very own Facebook test project:

http://coronalabs.s3.amazonaws.com/corona_bug.mov

I also confirmed this bug to go back to before 3.3.1 by testing the 990 build, so slap on my own face for blaming the 3.1.1 update. This bug has been here for a long time, and I see in some old code of ours that we’ve worked around it by checking the facebook response for post_id/request_id etc.

I’m still not sure about the session related bug, I’ll do some more testing and put up a video using your test app if I can find the exact way to reproduce it. [import]uid: 21746 topic_id: 34416 reply_id: 136811[/import]

haakon · January 3, 2013, 1:52am

Could it be a change in the Facebook 3.1.1 SDK?

https://github.com/mgcrea/cordova-facebook-connect/issues/22

Apparently since the latest facebook update you cannot request publishing permissions when initially logging in the user. Leave out the ‘publish_actions’ permission and you should be fine.

I’ll try that and post my findings. [import]uid: 21746 topic_id: 34416 reply_id: 137196[/import]

borderleap · January 3, 2013, 6:25am

"The operation couldn’t be completed. (com.facebook.sdk error 5.)"

I’m getting this error also when trying to upload an image. This was working in the latest public release, but I’m using v996 now and it’s not working.

The function I’m calling goes like this - I’ve replaced some of the vars with placeholder labels for reference…

function scene:uploadPictureToFacebook()  
  
 -- listener  
 local function fbListener( event )  
 if event.isError then  
 native.showAlert( "ERROR", event.response, { "OK" } )  
 else  
 if event.type == "session" and event.phase == "login" then  
  
 local attachment = {  
 message = "[Message goes here]",  
 source = { baseDir=system.DocumentsDirectory, filename=MY\_PATH\_TO\_SCREENSHOT, type="image" }  
 }  
 facebook.request( "me/photos", "POST", attachment )  
  
 elseif event.type == "request" then  
 native.showAlert( "Screenshot Uploaded!", "The image has been uploaded to your Facebook timeline.", { "Ok, thanks!" } )  
 end  
 end  
 end  
  
 -- authenticate with FB...  
 facebook.login( "MY\_APP\_ID", fbListener, { "publish\_stream" } )  
end

Has there been any update on this? Thanks. [import]uid: 131038 topic_id: 34416 reply_id: 137206[/import]

borderleap · January 3, 2013, 6:27am

“Apparently since the latest facebook update you cannot request publishing permissions when initially logging in the user. Leave out the ‘publish_actions’ permission and you should be fine.”

Any testing done on this? [import]uid: 131038 topic_id: 34416 reply_id: 137208[/import]

borderleap · January 3, 2013, 6:41am

fyi - I’m testing this now using “publish_actions” rather than “publish_stream”…

https://developers.facebook.com/docs/concepts/login/permissions-login-dialog/

"Permissions to write actions to a person’s timeline must be requested separately from read permissions. We currently support three publishing permissions: publish_actions, publish_stream, and publish_checkins. Moving forward, we recommend that apps only ask for publish_actions, as this permission encompasses the other two and we want to simplify the model. To ease the transition to this single permission, when asking for any one of these, the language presented to the person using the app is identical: “Social Hiking would like to post to your friends on your behalf.” [import]uid: 131038 topic_id: 34416 reply_id: 137209[/import]

borderleap · January 3, 2013, 7:00am

After more testing, it just plain won’t log me in at all - even with permissions changed to “publish_actions” as well as with permissions removed from the login() call.

Anyone experiencing this with the latest build? [import]uid: 131038 topic_id: 34416 reply_id: 137210[/import]

borderleap · January 3, 2013, 7:12am

Bug submitted. [import]uid: 131038 topic_id: 34416 reply_id: 137211[/import]

mfr · January 3, 2013, 7:43am

I also had the same problem with the latest build, couldn’t login or upload a picture anymore. But it actually worked on the iOS simulator, but not on the device. Then I removed the permissions and re-installed the Facebook App on my device and it worked again. But thats’s only tested on my device. [import]uid: 98060 topic_id: 34416 reply_id: 137213[/import]

haakon · December 30, 2012, 2:42pm

This is weird. The “session bug” I suggested above is not happening. The problem is with permissions. I have found the steps to reproduce the actual bug with your own sample project.

I made another video showing the 3 changes I made to your main.lua file, and the funky stuff happening when running it.

In short, using the publish_actions permission is what breaks your implementation (you are using the “deprecated” publish_stream permission). publish_actions works in daily build 990 and older, but not in builds after you updated to 3.1.1.

Facebook is very clear about the recommended permission to ask by an app:

Permissions to write actions to a person’s timeline must be requested separately from read permissions. We currently support three publishing permissions: publish_actions, publish_stream, and publish_checkins. Moving forward, we recommend that apps only ask for publish_actions, as this permission encompasses the other two and we want to simplify the model.

If you look at my video, you’ll see an error message in the status text field:

The operation couldn’t be completed. (com.facebook.sdk error 5.)

Video: http://coronalabs.s3.amazonaws.com/corona_bug_2.mov
main.lua: http://coronalabs.s3.amazonaws.com/main.lua

[import]uid: 21746 topic_id: 34416 reply_id: 136828[/import]

haakon · January 3, 2013, 1:31am

Any progress here? It’s not much job for you to verify the bug, I’ve documented it well, and you only need to run your own Facebook project.

This is a complete showstopper for using builds newer than 990. [import]uid: 21746 topic_id: 34416 reply_id: 137194[/import]

haakon · January 3, 2013, 1:52am

Could it be a change in the Facebook 3.1.1 SDK?

https://github.com/mgcrea/cordova-facebook-connect/issues/22

Apparently since the latest facebook update you cannot request publishing permissions when initially logging in the user. Leave out the ‘publish_actions’ permission and you should be fine.

I’ll try that and post my findings. [import]uid: 21746 topic_id: 34416 reply_id: 137196[/import]

borderleap · January 3, 2013, 6:25am

"The operation couldn’t be completed. (com.facebook.sdk error 5.)"

I’m getting this error also when trying to upload an image. This was working in the latest public release, but I’m using v996 now and it’s not working.

The function I’m calling goes like this - I’ve replaced some of the vars with placeholder labels for reference…

function scene:uploadPictureToFacebook()  
  
 -- listener  
 local function fbListener( event )  
 if event.isError then  
 native.showAlert( "ERROR", event.response, { "OK" } )  
 else  
 if event.type == "session" and event.phase == "login" then  
  
 local attachment = {  
 message = "[Message goes here]",  
 source = { baseDir=system.DocumentsDirectory, filename=MY\_PATH\_TO\_SCREENSHOT, type="image" }  
 }  
 facebook.request( "me/photos", "POST", attachment )  
  
 elseif event.type == "request" then  
 native.showAlert( "Screenshot Uploaded!", "The image has been uploaded to your Facebook timeline.", { "Ok, thanks!" } )  
 end  
 end  
 end  
  
 -- authenticate with FB...  
 facebook.login( "MY\_APP\_ID", fbListener, { "publish\_stream" } )  
end

Has there been any update on this? Thanks. [import]uid: 131038 topic_id: 34416 reply_id: 137206[/import]

borderleap · January 3, 2013, 6:27am

“Apparently since the latest facebook update you cannot request publishing permissions when initially logging in the user. Leave out the ‘publish_actions’ permission and you should be fine.”

Any testing done on this? [import]uid: 131038 topic_id: 34416 reply_id: 137208[/import]

borderleap · January 3, 2013, 6:41am

fyi - I’m testing this now using “publish_actions” rather than “publish_stream”…

https://developers.facebook.com/docs/concepts/login/permissions-login-dialog/

"Permissions to write actions to a person’s timeline must be requested separately from read permissions. We currently support three publishing permissions: publish_actions, publish_stream, and publish_checkins. Moving forward, we recommend that apps only ask for publish_actions, as this permission encompasses the other two and we want to simplify the model. To ease the transition to this single permission, when asking for any one of these, the language presented to the person using the app is identical: “Social Hiking would like to post to your friends on your behalf.” [import]uid: 131038 topic_id: 34416 reply_id: 137209[/import]