Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gapi.client is undefined — firefox add-on sdk #154

Open
wonderfly opened this issue Jan 7, 2015 · 21 comments
Open

gapi.client is undefined — firefox add-on sdk #154

wonderfly opened this issue Jan 7, 2015 · 21 comments

Comments

@wonderfly
Copy link
Contributor

From proje...@tragicmedia.com on July 14, 2014 02:37:26

Following these instructions: https://developers.google.com/+/web/api/javascript <script type="text/javascript">
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = ' https://apis.google.com/js/client:plusone.js?onload=signin'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
</script>

The gapi object that is available inside the signin() callback does not include gapi.client . In fact, I am getting gapi.client is undefined as a JS error.

I cannot call gapi.client.load('drive', 'v2', callback) since the client property is undefined.

This issue is only when using Firefox Add-on SDK and using cfx run to open a browser with the add-on I am developing being a sidebar element.

Can you enlighten me as to why this might be happening? If I run the html locally in firefox, it works fine and gapi.client is defined. If I do it as an add-on with cfx run, gapi.client is undefined.

Original issue: http://code.google.com/p/google-api-javascript-client/issues/detail?id=154

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on July 14, 2014 09:52:43

Hi, I'm not familiar with Firefox Add-on runtime environment. Are there environment-imposed restrictions on dynamic script loading or evaluation in this environment? Is "window" the global namespace? If the answers to these questions are not "no" and "yes", respectively, this might explain the behavior you're seeing. -Ben

@wonderfly
Copy link
Contributor Author

From proje...@tragicmedia.com on July 15, 2014 18:35:20

Thank you for the quick response!

  1. "window" should be the global namespace as far as I can tell.
  2. There are some restrictions on external script loading, but usually it just blocks the script from loading at all. From what I can tell this is setup correctly since the external script does load. It seems strange that the script loads fine, but that the response does not contain the full GAPI object. Do you have any idea what environment restrictions might cause the GAPI response to not include the client property? Again if the external script loads successfully, I am a little confused on what could be restricting the client property from loading?

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on July 16, 2014 17:22:38

The first script from apis.google.com in turn injects a second script node to load the main library payload. This combination allows versioning (by updating the small first-stage script) but simultaneously allows longer caching of the (larger) second-stage payload.

I would not be surprised if the gapi object were not fully usable until the second stage script loaded and executed.

@wonderfly
Copy link
Contributor Author

From proje...@tragicmedia.com on July 17, 2014 18:50:14

Oh I see.
Thank you for the update!

@wonderfly
Copy link
Contributor Author

From vinayakg...@gmail.com on October 03, 2014 09:39:59

What did you do for work around? I am seeing same issue with "gapi.auth.authorize". Full details here - http://stackoverflow.com/questions/26175836/how-to-add-onload-event-for-gapi

@wonderfly
Copy link
Contributor Author

From proje...@tragicmedia.com on October 06, 2014 23:22:50

Unfortunately, we have yet to be unable to find a workaround to get this to work in the Firefox environment. If you have any luck please let me know!

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on October 07, 2014 10:51:42

What script nodes from *.google.com are present in the DOM at the time your window['signin'] callback is invoked? And what is the type of window['gapi'] and window['gapi']['client'] ?

@wonderfly
Copy link
Contributor Author

From chris.ro...@tragicmedia.com on October 07, 2014 11:04:45

Script nodes:
cb=gapi.loaded_0
cb=gapi.loaded_1

window['gapi'] returns "object"
window['gapi']['client'] returns "undefined"

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on October 07, 2014 12:38:35

Can you share the full URLs of those scripts? Also, what does window.location.protocol evaluate to? And does your app include any Google-specific Content Security Policy directives? If so, what are they? I'm talking about these: https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives ) This may be set in the "csp" field of your app manifest ( https://developer.mozilla.org/en-US/Apps/CSP )

@wonderfly
Copy link
Contributor Author

From ntim...@gmail.com on October 21, 2014 09:54:12

It seems like the resource:/// protocol that is used by the add-on sdk is blocked by Google API. A solution would be to allow this protocol.

@wonderfly
Copy link
Contributor Author

From chris.ro...@tragicmedia.com on October 21, 2014 12:20:54

I assume you mean the permissions prt for cross domain content:

"permissions" : {
"cross-domain-content": [" https://plus.google.com ", " https://apis.google.com ", " https://mail.google.com ", "resource://*"]
}

But adding it in did not fix anything?

@wonderfly
Copy link
Contributor Author

From ntim...@gmail.com on October 23, 2014 03:43:48

No, I meant this is a bug on Google side, Google is not allowing resource:// URIs to access it's API (there's an Error 405 trying to load the api)

@wonderfly
Copy link
Contributor Author

From proje...@tragicmedia.com on October 27, 2014 17:13:22

@bsittler is there a workaround we can implement to get around the API loading restrictions? Or is this something that has to be fixed with the API? If it has to be fixed on the Google side, is there a way we can be notified when the fix has been deployed?

Thanks

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on October 27, 2014 17:19:17

Hi, I'm not sure which request is failing. Can you provide a trace of the failing request and its response? Thanks, -Ben

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on October 27, 2014 17:20:27

(and please strip out cookies or OAuth tokens from the trace. Capturing the trace in a signed-out browser session should work too.)

@wonderfly
Copy link
Contributor Author

From bsittler@google.com on October 27, 2014 17:33:50

Instructions on capturing a trace: http://www.softwareishard.com/blog/firebug/exporting-http-tracing-data-from-firebug/

@wonderfly
Copy link
Contributor Author

From chris.ro...@tragicmedia.com on October 28, 2014 14:09:20

Is there a recommended way to do this? CFX RUN opens sandbox environment which when I install the tracing add-on util, it requires a restart and doesnt even work in Firebug in that environment.

Then, if I export using CFX XPI -- install into normal Firefox browser -- I can't use Firebug on a panel nor on a sidebar item.

Whats the recommended way to accomplish your suggestion of capturing a trace?

@wonderfly
Copy link
Contributor Author

From chris.ro...@tragicmedia.com on November 21, 2014 20:11:12

to: bsittler@google.com

Can you give me an example or tutorial on how to set this up? I mentioned above how it was not working either with CFX RUN or even after exporting the add-on to use inside a regular Firefox browser.

Help please?

@aarroyoc
Copy link

Firefox addon sdk doesn't implement any type of DOM so if you want to use, for example Google OAuth2, you need the REST APIs like in this npm plugin - https://www.npmjs.com/package/addon-google-oauth2. It requires using jpm instead of cfx but works in a similar way.

@nt1m
Copy link

nt1m commented Apr 15, 2015

@antoinevg
Copy link

We're sitting with the same problem here with Trigger.io Forge which uses the content:// protocol to access local resources.

In general, given we've also had this issue with both the Angular and jQuery projects it would be great if everyone could stop assuming that http:// and https:// are the only transport protocols in existence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants