-
Notifications
You must be signed in to change notification settings - Fork 56
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
sidePanel API: allow specifying a web site via url
#438
Comments
Firefox is generally opposed to having the top level url being something other than the extension page. I believe most ways to affect an iframe by other extensions (adblockers) work in iframes inside extension pages, so that part of the issue does not affect Firefox (and Safari), and might be a Chromium-only issue. |
@xeenon expressed a similar view in today's WECG meeting. As a rough summary of his comments, even if a non-extension origin wouldn't have extension APIs exposed, top level views have some special considerations in Safari. |
So this issue can be resolved by making Chrome match the other browsers and allow other extensions in web iframes inside an extension by default or via an attribute. I guess a new issue should be opened about that? |
There is general consensus that this is the wrong solution to the problem, and would be solved by browsers providing a way for users to open a website in their relevant UI. There is interest in discussing if extensions should be able to inject in to frames which are part of other contexts like other extensions. Please feel free to file an issue about this. Related: #7 |
In fact, many extensions already deal with displaying other sites in an iFrame. With the advent of side panels, there are even more such extensions. Moreover, in 90% of cases, sites that are valuable to the user prohibit loading iFrames. The paradox is that the user needs sites with his data, but where there is data, there is almost always a ban on iFrames. It is also important to add that often, extensions do not just load other sites into an iFrame but do additional work: adapt the layout, styles, and integrate the loaded site into its context. For example, we enrich Google Tasks with a dark theme, which Google would never do, and transfer the selected text on the page to a Google Translate iFrame. The result is that extensions can already do what they want, but they need to change headers and weaken security. I think it would be cool if extensions had some kind of object that allows you to load any site as a full-fledged tab without changing the headers. |
As the wise men said —"if you can't beat it, lead it" 😂. |
The upcoming |
Thanks for the feedback @yankovichv. I think there is general interest in providing some sort of mechanism for embedding sites even if they set headers to disallow it. No specific proposals there yet, but I agree that's a problem worth solving. |
@oliverdunk I'd like to draft (or help with drafting) a proposal for this feature. Do you have any advice what should be in proposal or how it should look to maximize chances of it getting implemented? |
Hi Oleh! Just to check, do you mean having a way to embed content regardless of the headers? If so, I think a really good first step would be an analysis of what is already available on the platform (both fenced frames and controlledframe both jump to mind). You could then share that in a new issue where we can discuss if one of those proposals would be a good fit. |
Submitted proposal for API to embed pages in WebExtension bypassing CSP here #483 |
There are productivity sites that users would like to have in a side panel, and their amount/features exceeds that offered by extensions. Some browsers like Vivaldi even allow the user to pin any site in the side panel.
The workaround is problematic: currently an extension would have to use an
iframe
inside its sidePanel page, but that prevents other extensions from accessing the frame's contents (intentionally, because it's considered to be a part of extension's internal workflow), so it will evade extensions that block ads/trackers or security/privacy enhancers (now this is really really bad), userscripts/userstyles.Proposing to allow
default_url
in manifest.json'sside_panel
andurl
in chrome.sidePanel.setOptions.Alternatively, devise a mechanism of marking the iframe accessible to all other extensions.
The text was updated successfully, but these errors were encountered: