Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Iframes do not respect preload or other plugin infrastructure #863

Closed
carsonwright opened this issue Mar 4, 2018 · 12 comments
Closed

Iframes do not respect preload or other plugin infrastructure #863

carsonwright opened this issue Mar 4, 2018 · 12 comments
Labels

Comments

@carsonwright
Copy link

carsonwright commented Mar 4, 2018

Operation System: macOS High Sierra
Beaker Version: 7011

This is functional via electron 2.0.0-beta-1

session.setPreloads()

Having beaker api and extensions be able to perform on the webview and the webview's iframes would make the browser much more extensible and usable.

If there are other ways that would work that would also be awesome!

Context (I mean by this that the preloads.js doesn't run in iframes for Beaker)

@pfrazee
Copy link
Member

pfrazee commented Mar 5, 2018

Ah excellent, I missed that new feature in Electron. I'll be sure to add this when we take the dive into v2.

@pfrazee pfrazee added the enhancement Change that's on the roadmap label Mar 5, 2018
@pfrazee
Copy link
Member

pfrazee commented Apr 2, 2018

Waiting on electron/electron#12505

@pfrazee
Copy link
Member

pfrazee commented Apr 2, 2018

Word on the street is that this isn't going to be easy to implement in Electron. The recent Electron feature doesn't add support for iframes or workers. This may be a long way off.

@carsonwright
Copy link
Author

Thank you @pfrazee its interesting because previous PRs said it was, but I saw the referred to comments.
Thank you

@burtonator
Copy link

What's the status of this? Iframes are a big problem for realistic content rendering of web content.

@pfrazee
Copy link
Member

pfrazee commented Jun 16, 2019

Quick note on this: Electron should have the support I need. I think I can implement this but I'm unsure about how to handle permissions. I think if the site asks for write permissions while in an iframe, I'll have to auto-deny.

@andrewburgess
Copy link

@pfrazee is there any way to use the sandbox attribute? I'm not sure if it would be frowned upon to add browser specific values, but it might be beneficial for parent frames to restrict some of the Beaker specific APIs

There's also the experimental allow-storage-access-by-user-activation value, but I believe that's only available in Safari and Firefox at the moment. You might be able to see how they handle any prompts for write access though.

https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

@pfrazee
Copy link
Member

pfrazee commented Jun 16, 2019

@andrewburgess Thanks for the tips, I'll take a look. BTW was that you that submitted datcool to r/beakerbrowser?

@andrewburgess
Copy link

Yep, it's me!

@pfrazee
Copy link
Member

pfrazee commented Jun 16, 2019

Awesome, great site. I'm going to flair you for it

@brechtcs
Copy link

There might be a good case for supporting DatArchive and other Beaker APIs in same-origin (and non-sandboxed) iframes only. Going this route, I think the current permissions system would work alright without much changes.

@pfrazee
Copy link
Member

pfrazee commented Jun 20, 2019 via email

@pfrazee pfrazee closed this as completed May 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants