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

sidePanel API: allow specifying a web site via url #438

Closed
tophf opened this issue Aug 5, 2023 · 11 comments
Closed

sidePanel API: allow specifying a web site via url #438

tophf opened this issue Aug 5, 2023 · 11 comments
Labels
opposed: chrome Opposed by Chrome opposed: firefox Opposed by Firefox opposed: safari Opposed by Safari proposal Proposal for a change or new feature

Comments

@tophf
Copy link

tophf commented Aug 5, 2023

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's side_panel and url in chrome.sidePanel.setOptions.

Alternatively, devise a mechanism of marking the iframe accessible to all other extensions.

@xeenon xeenon added proposal Proposal for a change or new feature opposed: safari Opposed by Safari and removed needs-triage labels Aug 30, 2023
@zombie
Copy link
Collaborator

zombie commented Aug 31, 2023

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.

@zombie zombie added the opposed: firefox Opposed by Firefox label Aug 31, 2023
@dotproto
Copy link
Member

Firefox is generally opposed to having the top level url being something other than the extension page.

@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.

@tophf
Copy link
Author

tophf commented Aug 31, 2023

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?

@oliverdunk oliverdunk added the follow-up: chrome Needs a response from a Chrome representative label Sep 4, 2023
@oliverdunk oliverdunk added opposed: chrome Opposed by Chrome and removed follow-up: chrome Needs a response from a Chrome representative labels Sep 13, 2023
@oliverdunk
Copy link
Member

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

@oliverdunk oliverdunk closed this as not planned Won't fix, can't repro, duplicate, stale Sep 13, 2023
@yankovichv
Copy link

CleanShot 2023-09-14 at 14 23 21@2x

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.

@yankovichv
Copy link

As the wise men said —"if you can't beat it, lead it" 😂.

@tophf
Copy link
Author

tophf commented Sep 14, 2023

The upcoming <controlledframe> is capable of that, but it's not allowed for extensions yet, only for IWA.

@oliverdunk
Copy link
Member

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.

@OlegWock
Copy link

@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?

@oliverdunk
Copy link
Member

@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.

@OlegWock
Copy link

OlegWock commented Nov 4, 2023

Submitted proposal for API to embed pages in WebExtension bypassing CSP here #483

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
opposed: chrome Opposed by Chrome opposed: firefox Opposed by Firefox opposed: safari Opposed by Safari proposal Proposal for a change or new feature
Projects
None yet
Development

No branches or pull requests

7 participants