We are migrating from deprecated Google Sign-in (basically gapi.auth and gapi.auth2 methods) into the new Google identity services (google.accounts.oauth2). More info here
We are using the authorization solely for Google picker. The problem is, beforehand (it seems) the library didn't return access_token in their gapi.auth.authorize, which was an indication that something wrong is going on and we've displayed "3rd party cookies blocked" message.
After the migration, the Google identity does not need any cookies, whatsoever, Google picker is somewhat unaware and stops working with 3rd party cookies blocked.
After the picker is successfully loaded, he prompts the user to SignIn (even though it just received a working token via setOAuthToken). After clicking the SignIn twice in the iframe, there is some malfunction error. Nothing is ever opened. NO callbacks are aware of this, no errors can be caught.
This behavior can be directly controled by the 3rd party cookie block. If the cookies are allowed. The exact same flow (and code) opens google drive picker (via build and setVisible) and everything works as expected.
The question is.
Drive Picker and Drive API Third-party cookies
This has been reported as an issue from the community, I would highly suggest to also provide the feedback and insight regarding your concerns and future alternatives:
Replying to your questions:
How to catch this 3rd party cookie error? Or any errors in the iframe whatsoever?
As suggested over the Issue tracker, it is not possible to catch information about the matter.
Why the picker requires 3rd party cookies?
It would be a great idea to request a better documentation on why over the issue tracker, as it was also suggested on a previous old post:
I notice that other types of Drive API process that can be troubleshooted generally recommend enabling or as an alternative to add an exception for accounts.google.com.
Should I do something on the picker side for the migration as well?
It seems you have followed the process of migration correctly, this is only a limitation from Drive Picker itself or the Drive API needing access to those cookies to run properly, might be a good test the exception suggested in the previous answer.
References: