Open
Bug 1318532
Opened 8 years ago
Updated 1 year ago
Support browser elements in WebExtensions
Categories
(WebExtensions :: General, enhancement, P5)
WebExtensions
General
Tracking
(Not tracked)
NEW
People
(Reporter: cvan, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-needed, Whiteboard: [webvr][design-decision-approved])
Attachments
(5 files)
Implement the `<webview>` WebExtensions API à la Chrome Apps' https://developer.chrome.com/apps/tags/webview.
With this API, developers can implement browser-like functionality (functioning like a top-level browser window to embedded content, sandboxed such that `X-Frame-Options` and `Same-Origin` are not issues) in their extensions.
Firefox OS introduced a similar API, the Browser API (`<iframe mozbrowser>`): https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
With WebExtensions, we would instead let browser extensions to use `<webview>`:
<webview src="https://www.google.com/" partition="persist: static"></webview>
There is also the `webview` key in the `manifest.json` to support: https://developer.chrome.com/apps/tags/webview#local_resources
There are also a ton of interfaces, methods, and events to support: https://developer.chrome.com/apps/tags/webview#toc
|
||
Comment 1•8 years ago
|
||
We're probably going to add support for <iframe mozbrowser>, but a <webview> clone is extremely unlikely.
Whiteboard: [webvr] → [webvr][design-decision-needed]
|
Reporter | |
Comment 2•8 years ago
|
||
Kris, that sounds perfect. How much work and what conversations need to be had to make `<iframe mozbrowser>` work with We Extensions? It would completely satisfy our use cases. If needed, we can likely get some help (externally or internally) here too, if we can get some guidance from the WebExtensions team.
|
|
||
Updated•8 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: General
Summary: Implement `<webview>` WebExtensions API → Support <iframe mozbrowser> in WebExtensions
|
||
Comment 3•8 years ago
|
||
Hopefully this can be prioritized for existing add-ons like Tile Tabs and also for chrome extensions that try to disable X-Frame-Options.
|
|
||
Comment 4•8 years ago
|
||
Can this get prioritized? This is pretty vital for Tile Tabs, and for security.
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(amckay)
|
||
Updated•8 years ago
|
webextensions: --- → ?
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(amckay)
|
|
||
Updated•8 years ago
|
Assignee: nobody → ntim.bugs
|
|
||
Comment 5•8 years ago
|
||
Implementation plan:
https://gist.github.com/nt1m/6d5c7fea75aa3baaf3fee03ec00a0494
|
|
||
Comment 6•8 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #5)
> Implementation plan:
> https://gist.github.com/nt1m/6d5c7fea75aa3baaf3fee03ec00a0494
Hey Andy, I plan to work on this soon, can this plan be closely evaluated (including which APIs to prioritize, the issues I've mentioned, ...) ?
I can't act on this bug until there's a clear plan of what we want to expose to WebExtensions and how we want to expose it.
|
|
||
Updated•8 years ago
|
Flags: needinfo?(amckay)
| Comment hidden (mozreview-request) |
| Comment hidden (mozreview-request) |
|
||
Comment 9•8 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848278 [details]
Bug 1318532 - Support <iframe mozbrowser> in WebExtension documents.
https://reviewboard.mozilla.org/r/121210/#review123510
I can review this technically, but I don't know what we want to expose to addons. Someone else needs to give some approval first.
On IRC I was told that dev-addons would be perhaps a good place to ask feedback.
::: dom/html/nsGenericHTMLFrameElement.cpp:379
(Diff revision 1)
>
> static bool
> PrincipalAllowsBrowserFrame(nsIPrincipal* aPrincipal)
> {
> + // WebExtension documents should have access to <iframe mozbrowser>
> + nsString addonId;
So I still wonder if we actually want to expose mozbrowser to WebExtensions. Shouldn't WebExtensions be cross-browser addons, so they should support same APIs.
mozbrowser is very Gecko specific.
Someone who has more knowledge about WebExtensions my approve this one.
::: dom/html/nsGenericHTMLFrameElement.cpp:397
(Diff revision 1)
> }
>
> +bool
> +nsGenericHTMLFrameElement::JSContextAllowsBrowserFrame(JSContext* cx, JSObject* /* unused */)
> +{
> + return PrincipalAllowsBrowserFrame(nsContentUtils::SubjectPrincipal(cx));
So whenever addon JS accesses an iframe, any iframe, it would get prototype object with mozbrowser methods.
If that is what we want, fine, but I'm not the right person to say that is ok.
Attachment #8848278 -
Flags: review?(bugs)
|
|
||
Comment 10•8 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848279 [details]
Bug 1318532 - Force remote='true' and noisolation='true' to WebExtensions mozbrowser iframes.
https://reviewboard.mozilla.org/r/121212/#review123512
This needs also feedback from someone more familiar with webextensions. But fix those technical issues too.
::: dom/base/nsFrameLoader.cpp:2251
(Diff revision 1)
> return Preferences::GetBool("dom.ipc.browser_frames.oop_by_default", false);
> }
>
> // Otherwise, we're remote if we have "remote=true" and we're either a
> // browser frame or a XUL element.
> - return (OwnerIsMozBrowserFrame() ||
> + return (OwnerIsMozBrowserFrame() && browserFrame->GetRemote()) ||
Why you call GetRemote() twice here? Just store the return value of the first one?
::: dom/html/nsGenericHTMLFrameElement.cpp:529
(Diff revision 1)
> nsGenericHTMLFrameElement::GetIsolated(bool *aOut)
> {
> *aOut = true;
>
> + // Never isolate browser frames for WebExtensions
> + nsString addonId;
So we don't even want to be able to override this value in addons?
::: dom/html/nsGenericHTMLFrameElement.cpp:547
(Diff revision 1)
> *aOut = !HasAttr(kNameSpaceID_None, nsGkAtoms::noisolation);
> return NS_OK;
> }
>
> +/* [infallible] */ nsresult
> +nsGenericHTMLFrameElement::GetRemote(bool *aOut)
This doesn't look right in case of nested processes,
at least in case we don't have MOZ_NESTED_OOP_TABS or dom.ipc.tabs.nested.enabled enabled.
And maybe even dom.ipc.browser_frames.oop_by_default should be checked here.
Attachment #8848279 -
Flags: review?(bugs) → review-
|
|
||
Comment 11•8 years ago
|
||
| mozreview-review-reply | ||
Comment on attachment 8848278 [details]
Bug 1318532 - Support <iframe mozbrowser> in WebExtension documents.
https://reviewboard.mozilla.org/r/121210/#review123510
> So I still wonder if we actually want to expose mozbrowser to WebExtensions. Shouldn't WebExtensions be cross-browser addons, so they should support same APIs.
> mozbrowser is very Gecko specific.
> Someone who has more knowledge about WebExtensions my approve this one.
We do. Chrome has a similar <webview> element that they expose to extensions with a special permission, but it's a separate Chrome-specific API, not part of the extension API, so we don't want to implement it.
We need to add a separate permission for this, though. Either "mozbrowser" or Google's "webview" permission.
> So whenever addon JS accesses an iframe, any iframe, it would get prototype object with mozbrowser methods.
>
> If that is what we want, fine, but I'm not the right person to say that is ok.
I don't think we want that.
|
|
||
Comment 12•8 years ago
|
||
| mozreview-review-reply | ||
Comment on attachment 8848279 [details]
Bug 1318532 - Force remote='true' and noisolation='true' to WebExtensions mozbrowser iframes.
https://reviewboard.mozilla.org/r/121212/#review123512
I don't think we want this either. The mozbrowser API should be available to add-ons with a special permissino, but it shouldn't apply to all iframes by default. We might want to consider forbidding them from loading webcontent into regular iframes in privileged pages, though.
|
||
Comment 13•8 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #11)
> We do. Chrome has a similar <webview> element that they expose to extensions
> with a special permission, but it's a separate Chrome-specific API, not part
> of the extension API, so we don't want to implement it.
>
> We need to add a separate permission for this, though. Either "mozbrowser"
> or Google's "webview" permission.
<webview> is only available for chrome apps, not extensions. Why are we doing that?
|
|
||
Comment 14•8 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #11)
> > So whenever addon JS accesses an iframe, any iframe, it would get prototype object with mozbrowser methods.
> >
> > If that is what we want, fine, but I'm not the right person to say that is ok.
>
> I don't think we want that.
So the question is how this all should work then.
If one does var el = document.createElement("iframe"); the prototype would be the normal HTMLIFrameElement.
Then el.setAttribute("mozbrowser", "true"); couldn't suddenly change prototype, or at least I think it shouldn't
Though, perhaps we could use some CustomElement setup here?
|
|
||
Comment 15•8 years ago
|
||
|
|
||
Comment 16•8 years ago
|
||
(In reply to [:fabrice] Fabrice Desré from comment #13)
> <webview> is only available for chrome apps, not extensions. Why are we
> doing that?
From what I'm told, it's available to extensions too. Regardless, we have extensions that need this feature.
(In reply to Olli Pettay [:smaug] from comment #14)
> So the question is how this all should work then.
> If one does var el = document.createElement("iframe"); the prototype would
> be the normal HTMLIFrameElement.
> Then el.setAttribute("mozbrowser", "true"); couldn't suddenly change
> prototype, or at least I think it shouldn't
> Though, perhaps we could use some CustomElement setup here?
OK, I think I'm fine with this as long as we require a separate permission for mozbrowser iframes, if this is how it works for other consumers of the API.
|
|
||
Comment 17•8 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #16)
> (In reply to [:fabrice] Fabrice Desré from comment #13)
> > <webview> is only available for chrome apps, not extensions. Why are we
> > doing that?
>
> From what I'm told, it's available to extensions too. Regardless, we have
> extensions that need this feature.
That's incorrect that chrome extensions support <webview>, but nevermind. I'm not against exposing a <webview> tag to extensions (that will make possible to write a full browser just as a WebExt!), but <iframe mozbrowser> is extremely gecko-specific.
There is almost no chance any other browser will implement it, even Servo (the current implementation is a burden that will be removed). Instead it would be better to implement a new element and design the API by taking some clues from the Electron <webview> or even the Android WebView.
|
|
||
Updated•8 years ago
|
webextensions: ? → ---
Flags: needinfo?(amckay)
|
||
Comment 18•7 years ago
|
||
Hi Christopher, Tim, Olli, Fabrice, and Kris -- this has been added to the agenda for the June 13 WebExtension APIs triage meeting. Will you be able to join us?
Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting
Agenda: https://docs.google.com/document/d/1A_M0YD86Plcs6eHyM2KXkDXY074BHZ3fZvaWXCljQLI/edit#heading=h.34n4lirhljve
|
|
||
Comment 19•7 years ago
|
||
This idea has been approved, but more internal discussions will be needed to figure out how to implement it.
|
|
||
Updated•7 years ago
|
Priority: -- → P5
Whiteboard: [webvr][design-decision-needed] → [webvr][design-decision-approved]
|
|
||
Updated•7 years ago
|
Flags: needinfo?(ntim.bugs)
|
|
||
Comment 21•7 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848279 [details]
Bug 1318532 - Force remote='true' and noisolation='true' to WebExtensions mozbrowser iframes.
https://reviewboard.mozilla.org/r/121212/#review162692
::: dom/html/nsGenericHTMLFrameElement.cpp:529
(Diff revision 1)
> nsGenericHTMLFrameElement::GetIsolated(bool *aOut)
> {
> *aOut = true;
>
> + // Never isolate browser frames for WebExtensions
> + nsString addonId;
No, I don't think this capibility should be exposed to add-ons.
::: dom/html/nsGenericHTMLFrameElement.cpp:547
(Diff revision 1)
> *aOut = !HasAttr(kNameSpaceID_None, nsGkAtoms::noisolation);
> return NS_OK;
> }
>
> +/* [infallible] */ nsresult
> +nsGenericHTMLFrameElement::GetRemote(bool *aOut)
I can't remember the conversation we had about this, sorry, what should be set in this case ?
| Comment hidden (mozreview-request) |
| Comment hidden (mozreview-request) |
|
|
||
Comment 24•7 years ago
|
||
Someone who understands web extensions better need to review this too.
(it is unclear to me why we want to expose gecko internal mozbrowser API to extensions.)
|
|
||
Comment 25•7 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848278 [details]
Bug 1318532 - Support <iframe mozbrowser> in WebExtension documents.
https://reviewboard.mozilla.org/r/121210/#review163158
::: dom/html/nsGenericHTMLFrameElement.h:82
(Diff revision 2)
> mozilla::ErrorResult& aRv);
>
> static void InitStatics();
> static bool BrowserFramesEnabled();
>
> + static bool JSContextAllowsBrowserFrame(JSContext* cx, JSObject* /* unused */);
aCx
::: dom/html/nsGenericHTMLFrameElement.cpp:326
(Diff revision 2)
>
> static bool
> PrincipalAllowsBrowserFrame(nsIPrincipal* aPrincipal)
> {
> + // WebExtension documents should have access to <iframe mozbrowser>
> + nsString addonId;
nsAutoString
::: dom/html/nsGenericHTMLFrameElement.cpp:327
(Diff revision 2)
> static bool
> PrincipalAllowsBrowserFrame(nsIPrincipal* aPrincipal)
> {
> + // WebExtension documents should have access to <iframe mozbrowser>
> + nsString addonId;
> + aPrincipal->GetAddonId(addonId);
Based on comment 16 this isn't what we want.
"as long as we require a separate permission for mozbrowser iframes"
Attachment #8848278 -
Flags: review?(bugs) → review-
|
|
||
Comment 26•7 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848279 [details]
Bug 1318532 - Force remote='true' and noisolation='true' to WebExtensions mozbrowser iframes.
https://reviewboard.mozilla.org/r/121212/#review163184
::: dom/base/nsFrameLoader.cpp:2299
(Diff revision 2)
>
> // Otherwise, we're remote if we have "remote=true" and we're either a
> // browser frame or a XUL element.
> - return (OwnerIsMozBrowserFrame() ||
> - mOwnerContent->GetNameSpaceID() == kNameSpaceID_XUL) &&
> + return (OwnerIsMozBrowserFrame() && isRemote) ||
> + (mOwnerContent->GetNameSpaceID() == kNameSpaceID_XUL &&
> mOwnerContent->AttrValueIs(kNameSpaceID_None,
align the params properly.
::: dom/html/nsGenericHTMLFrameElement.cpp:526
(Diff revision 2)
> nsGenericHTMLFrameElement::GetIsolated(bool *aOut)
> {
> *aOut = true;
>
> + // Never isolate browser frames for WebExtensions
> + nsString addonId;
nsAutoString
::: dom/html/nsGenericHTMLFrameElement.cpp:546
(Diff revision 2)
> }
>
> +/* [infallible] */ nsresult
> +nsGenericHTMLFrameElement::GetRemote(bool *aOut)
> +{
> + nsString addonId;
nsAutoString
Attachment #8848279 -
Flags: review?(bugs) → review+
| Comment hidden (mozreview-request) |
| Comment hidden (mozreview-request) |
|
||
Comment 29•7 years ago
|
||
| mozreview-review | ||
Comment on attachment 8848278 [details]
Bug 1318532 - Support <iframe mozbrowser> in WebExtension documents.
https://reviewboard.mozilla.org/r/121210/#review163950
The code looks fine to me with the nits below. But I agree with smaug and fabrice: why are we exposign this Gecko-specific API, with a Gecko-specific name that no one else will likely implement? I see absolutely no information about that in the bug.
::: dom/html/nsGenericHTMLFrameElement.cpp:327
(Diff revision 3)
> static bool
> PrincipalAllowsBrowserFrame(nsIPrincipal* aPrincipal)
> {
> + // WebExtension documents with "mozbrowser" permission
> + // should have access to <iframe mozbrowser>
> + nsAutoString perm = NS_LITERAL_STRING("mozbrowser");
NS_NAMED_LITERAL_STRING if you really need a separate variable here.
That said, if you just use nsContentUtils::PrincipalHasPermission I don't think you'll even need the separate variable.
::: dom/html/nsGenericHTMLFrameElement.cpp:342
(Diff revision 3)
> NS_ENSURE_SUCCESS(rv, false);
> return permission == nsIPermissionManager::ALLOW_ACTION;
> }
>
> +bool
> +nsGenericHTMLFrameElement::JSContextAllowsBrowserFrame(JSContext* cx, JSObject* /* unused */)
This isn't about the JSContext allowing anything. It's about the current compartment on it allowing things. Probably best to call it "CallerAllowsBrowserFrame" instead.
::: dom/html/nsGenericHTMLFrameElement.cpp:342
(Diff revision 3)
> NS_ENSURE_SUCCESS(rv, false);
> return permission == nsIPermissionManager::ALLOW_ACTION;
> }
>
> +bool
> +nsGenericHTMLFrameElement::JSContextAllowsBrowserFrame(JSContext* cx, JSObject* /* unused */)
aCx.
::: dom/html/nsGenericHTMLFrameElement.cpp:344
(Diff revision 3)
> }
>
> +bool
> +nsGenericHTMLFrameElement::JSContextAllowsBrowserFrame(JSContext* cx, JSObject* /* unused */)
> +{
> + return PrincipalAllowsBrowserFrame(nsContentUtils::SubjectPrincipal(cx));
Do you really need the permission manager bits here? Because if not, you could just use nsContentUtils::CallerHasPermission.
I wonder whether we should have a nicer webidl syntax for this....
Attachment #8848278 -
Flags: review?(bzbarsky)
|
|
||
Comment 30•7 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #29)
> Comment on attachment 8848278 [details]
> Bug 1318532 - Support <iframe mozbrowser> in WebExtension documents.
>
> https://reviewboard.mozilla.org/r/121210/#review163950
>
> The code looks fine to me with the nits below. But I agree with smaug and
> fabrice: why are we exposign this Gecko-specific API, with a Gecko-specific
> name that no one else will likely implement? I see absolutely no
> information about that in the bug.
It's been marked [design-decision-approved] and Kris mentioned that would be the way to go as a full <webview> implementation would be very unlikely.
Flags: needinfo?(ntim.bugs)
|
||
Updated•7 years ago
|
Keywords: dev-doc-needed
|
|
||
Comment 31•7 years ago
|
||
> It's been marked [design-decision-approved]
Right, but is the reasoning for that public somewhere? Are we doing this because we think it's the Right Thing, or because we're pressed for time and need to get some specific add-ons working and its expedient? And if the latter, should the permission name perhaps reflect this (e.g. "deprecated-mozbrowser" or some such) and a followup bug be created for the solution we _do_ think is the Right Thing?
> and Kris mentioned that would be the way to go as a full <webview> implementation would be very unlikely.
"<iframe mozbrowser>" and "Chrome-compatible <webview>" are not the only two options here. For example, the end of comment 17 indicates another option which may have been better architecturally.
|
|
||
Comment 32•7 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #31)
> > It's been marked [design-decision-approved]
>
> Right, but is the reasoning for that public somewhere? Are we doing this
> because we think it's the Right Thing, or because we're pressed for time and
> need to get some specific add-ons working and its expedient? And if the
> latter, should the permission name perhaps reflect this (e.g.
> "deprecated-mozbrowser" or some such) and a followup bug be created for the
> solution we _do_ think is the Right Thing?
There is no pressing need for this or need for expediency (that I am aware of).
|
||
Comment 33•7 years ago
|
||
Andy,
From my perspective there is a pressing need for <iframe mozbrowser>.
I am the developer of the Tile Tabs and Tile View add-ons, with around 70,000 users. These add-ons have a loyal following and are unique in allowing multiple tabs to displayed and compared side-by-side in the same browser window.
I have developed a WebExtensions replacement add-on, called Tile Tabs WE, but because of the limitations of the WebExtensions API's, the tabs have to be tiled in separate browser windows, rather than in the same browser window. This add-on works, but is slow when tiling, generally not very slick, and there is too much chrome displayed taking up valuable screen real estate.
I have recently developed another WebExtensions add-on, called Tile Pages WE, which will be the true successor to the original Tile Tabs and Tile View. This add-on tiles multiple pages within the same browser window, just like the original Tile Tabs and Tile View.
Tile Pages WE is fully working and currently built using normal <iframe> elements. Obviously, Tile Pages WE cannot be released at present because of the security issues associated with <iframe> elements.
However, as soon as <iframe mozbrowser> elements are available, Tile Pages WE can be modified very quickly to use these elements instead of normal <iframe> elements, and can then be released to provide a migration path for users.
Is there a problem making <iframe mozbrowser> in the interim, even if it is not the long-term solution?
Flags: needinfo?(amckay)
|
|
||
Comment 34•7 years ago
|
||
Well you need to get the approval of developers to land code and that's not me. Some developers have expressed concern about this API, I think those concerns should be addressed.
Flags: needinfo?(amckay)
|
|
||
Comment 35•7 years ago
|
||
Tim, Boris, Kris,
As far as I can see from the comments above, the only significant issue is whether <iframe mozbrowser> is an expedient short-term solution (to get some specific add-ons working) or is a long-term solution.
From my perspective, I have a pressing need for <iframe mozbrowser>, so that I can test and release my Tile Pages WE add-on (the successor to Tile Tabs) prior to the release of Firefox 57.
If there is any doubt about whether this is gong to be the long-term solution, then using the term "deprecated-mozbrowser" seems a good idea.
Are there other issues preventing implementation moving forwards?
Flags: needinfo?(bzbarsky)
|
|
||
Comment 36•7 years ago
|
||
I honestly don't have a strong opinion here; I trust Kris and Shane to make API decisions like this. I just want to make sure that we're not painting outselves into corners we do not want to be in.
Flags: needinfo?(bzbarsky)
|
|
||
Comment 37•7 years ago
|
||
If the corner is "no other webext implementor will support this", this is kind of guaranteed. So maybe involve the people involved in the WebExt standardization (my apologies if they are already in this bug).
|
|
||
Comment 38•7 years ago
|
||
The corner I have in mind is if a few years down the road we want to remove it for some reason, or change its behavior, and can't.
|
|
||
Comment 40•7 years ago
|
||
Looks like this is blocked until the spec stuff is sorted out.
Flags: needinfo?(ntim.bugs)
|
|
||
Updated•7 years ago
|
Assignee: ntim.bugs → nobody
|
||
Comment 41•7 years ago
|
||
>The corner I have in mind is if a few years down the road we want to remove it for some reason, or change its behavior, and can't.
I'd say Quantum has established that there are no limits to making changes to existing functionality, so this doesn't seem like an argument that can be made now. Given the speed of spec committees, an interim solution would likely provide years of useful service. Seems like a waste to have implementation available and not utilize it.
|
|
||
Updated•7 years ago
|
Attachment #8848278 -
Flags: review?(lgreco)
|
||
Updated•7 years ago
|
|
|
||
Comment 42•7 years ago
|
||
(In reply to [:fabrice] Fabrice Desré from comment #37)
> If the corner is "no other webext implementor will support this", this is
> kind of guaranteed. So maybe involve the people involved in the WebExt
> standardization (my apologies if they are already in this bug).
We're way past that. Our goal is compatibility, but beyond that we want to implement new and useful functionality for extensions and it doesn't necessarily need to be something in any standardization process. We have extensions today doing work arounds that may be less desirable than having mozbrowser exposed.
IMO painting us into a corner would be basing this on top of some code that nobody wants to maintain and that ends up presenting problems in future directions of the browser and core code base itself. If we accept that we will keep mozbrowser support in the platform, then exposing that to extensions should proceed.
|
|
||
Comment 43•7 years ago
|
||
"But I agree with smaug and fabrice: why are we exposign this Gecko-specific API, with a Gecko-specific name that no one else will likely implement? I see absolutely no information about that in the bug."
ntim:
I think there needs to be a document with a concise reasoning and use cases. There's too many little tid-bits hidden throughout this and other bugs that contribute to that, but it's too hard to put together easily.
I think the naming is flexible, as long as it is not named something that it is not (ie. `<webview>`).
|
|
||
Comment 44•7 years ago
|
||
Honestly I don't mind what you will choose to do, but I know for sure that the mozbrowser implementation has grown organically from the early b2g days and that it's not an ideal design.
|
|
||
Comment 45•7 years ago
|
||
(In reply to [:fabrice] Fabrice Desré from comment #44)
> I know for sure that
> the mozbrowser implementation has grown organically from the early b2g days
> and that it's not an ideal design.
This is what concerns me most. I don't know the background or details of that implementation, whether it has or will bitrot, etc. If it's a bad idea technically to rely on it then this all becomes moot.
|
||
Comment 46•7 years ago
|
||
Also, the legacy Shumway extension made use of `<iframe mozbrowser remote>` to force the Flash runtime into a separate process, although this might not be necessary if bug 1429896 and bug 1443253 get resolved, which will make all `<iframe>`s run Out of Process.
Blocks: shumway-webext
|
||
Updated•7 years ago
|
|
||
Comment 48•6 years ago
|
||
Would this change also fix bug 1467417, i.e. allow WebExtensions to interfere with that HTML content? If so, bug 1467417 could be solved by this here completely and would be a duplicate.
|
||
Updated•6 years ago
|
Product: Toolkit → WebExtensions
|
|
||
Comment 49•6 years ago
|
||
Changing the URL to the `<iframe mozbrowser>` documentation on MDN.
|
|
||
Updated•6 years ago
|
Flags: needinfo?(kmaglione+bmo)
|
|
||
Comment 50•6 years ago
|
||
This extension is a prototype and is only for evaluation by developers.
|
|
||
Comment 51•6 years ago
|
||
As a demonstrator of how useful <iframe mozbrower> elements (or out-of-process <iframe> elements) could be, I have developed a prototype WebExtension (Tile Pages WE) with similar functionality to my legacy Tile Tabs extension.
The key features of Tile Page WE are:
- Several web pages can be tiled in almost any layout within a single tab.
- Web pages in other tabs can be assigned into existing tiles.
- Bookmarks can be dragged into existing tiles or Shift+dragged to create new tiles.
- Links in a tiled web page can be opened in an adjacent tile.
- Web pages in adjacent tiles can be synchronized scrolled.
- Splitters can be dragged to resize tiles.
- Layouts can be saved (with or without web page URLs) and can be re-opened.
For the moment, Tile Pages WE uses sandboxed <iframe> elements to tile several web pages within a tab. Optionally, Tile Pages WE removes X-Frame-Options and CSP 'frame-ancestors' directives from the web pages loaded into the <iframe> tiles, but not from nested frames within the framed web pages.
It is not clear whether Tile Pages WE in its current state is sufficiently secure, but the following points are relevant:
- The container page is an add-on page and is not hostile.
- The container page (moz-extension:) has a different origin from those of the framed web pages (http: or https:).
- The sandbox prevents scripts running in the framed web pages.
- The sandbox applies to all nested frames within the framed web pages.
Tile Pages WE 0.8 is attached for evaluation purposes only.
|
|
||
Comment 52•6 years ago
|
||
Hi Mike, Would it be possible to get a clear path forward here ? This API would allow bypassing CSP in <iframe> in a secure way, which would solve many useful use-cases. One use-case is the Tile Tabs use case: https://www.youtube.com/watch?v=HPO3wGM9qXw . The current way of bypassing CSP is just to override and remove the CSP for a site, which isn't very secure and doesn't scale (since you can't bypass all websites' CSP).
Flags: needinfo?(mconca)
|
|
||
Comment 53•6 years ago
|
||
|
|
||
Comment 54•6 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #52)
Hi Mike, Would it be possible to get a clear path forward here ? This API would allow bypassing CSP in <iframe> in a secure way, which would solve many useful use-cases. One use-case is the Tile Tabs use case: https://www.youtube.com/watch?v=HPO3wGM9qXw . The current way of bypassing CSP is just to override and remove the CSP for a site, which isn't very secure and doesn't scale (since you can't bypass all websites' CSP).
Sorry, Tim, but we are still going to hold on this for now. The use cases are clear and valid, but the near-term focus for the team is on extension security and protecting users from malicious behavior. Expanding the API via this functionality increases the potential attack vectors we need to evaluate, something we don't want to do at this time. Also, we need to let Project Fission run a bit longer so that we understand exactly how OOP iframes and complete site isolation might impact this type of API.
Type: defect → enhancement
Flags: needinfo?(mconca)
|
|
||
Updated•5 years ago
|
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1574886,
https://bugzilla.mozilla.org/show_bug.cgi?id=1614462 →
Summary: Support <iframe mozbrowser> in WebExtensions → Support browser elements in WebExtensions
|
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•