Detect embedded and skip addons

[humitos]

Check if addons library is being loaded inside an iframe, and skip loading it.

Closes #412

[stsewd]

I think this should be an option. We have at least one customer on .com that makes use of iframes, where it does need to show the flyout.

[humitos]

I think this should be an option.

Hrm, good point. I don't think we should expose this to users, since it seems to be pretty complex/advanced/confusing and probably not useful for 99% of our users. However, I think we should probably have an option internally for this and enable/disable it via support request.

We have at least one customer on .com that makes use of iframes, where it does need to show the flyout.

Do they have public docs where I can see how they are using iframes?

[stsewd]

Do they have public docs where I can see how they are using iframes?

If I remember correctly, their use case was to load their private documentation using a sharing token from an iframe, probably from inside their application.

However, I think we should probably have an option internally for this and enable/disable it via support request.

We can also expose an option as a query parameter, since the parent page should be the one that decides if the flyout should be shown. This is since users can embed docs they don't have control over. I imagine something like ?rtd-disable-flyout, users embedding docs and that don't want to show the flyout there can include the page with that query.

[humitos]

This is since users can embed docs they don't have control over.

I'm not too worried about this case.

I imagine something like ?rtd-disable-flyout, users embedding docs and that don't want to show the flyout there can include the page with that query.

I think we want to depend on the user for this. How this approach will solve the current problem we have? The user will need to rebuild all their documentation and probably modify the Sphinx extension's code to add that query attribute --which seems pretty complex for regular users.

I think the general rule we were using makes sense, since it follows what we used to have:

• if it's embed, don't enable addons
• if it's embed and there is a config that force addons, enable adons
• if it's not embed, always enable addons

That "config that forces addons" will be a META tag as we are doing with other things we want to communicate from the backend, and it will be a field in AddonsConfig so it can be manged per project. It won't be exposed to users and managed via support request.

[stsewd]

I think we want to depend on the user for this. How this approach will solve the current problem we have? The user will need to rebuild all their documentation and probably modify the Sphinx extension's code to add that query attribute --which seems pretty complex for regular users.

They just need to update the target URL, that's not complex, they are already providing a URL. And that doesn't require users to ask us to disable the option on docs they don't own.

[humitos]

I think we want to depend on the user for this.

I missed typed this. I meant here I think we don't want to depend on the user for this.

[humitos]

I will add an option in the server that by default skips loading the addons in iframes, but that we can manually force injecting addons for those users requiring this feature.

[humitos]

I changed the approach here to use addons.configs.load_when_embedded field from the API. I realized there is no need to use HTML meta tags for this particular case and it's easier, simpler and better to use an API field instead.