Christopher Van Wiemeersch [:cvan] Reporter
	Description • 8 years ago

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

	Kris Maglione [:kmag]
	Comment 1 • 8 years ago

We're probably going to add support for <iframe mozbrowser>, but a <webview> clone is extremely unlikely.

	Christopher Van Wiemeersch [:cvan] 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.

	Tim Nguyen :ntim
	Comment 3 • 7 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.

	Tim Nguyen :ntim
	Comment 4 • 7 years ago

Can this get prioritized? This is pretty vital for Tile Tabs, and for security.

	Tim Nguyen :ntim
	Comment 5 • 7 years ago

Implementation plan:
https://gist.github.com/nt1m/6d5c7fea75aa3baaf3fee03ec00a0494

	Tim Nguyen :ntim
	Comment 6 • 7 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 7 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 10 • 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/#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.

	Kris Maglione [:kmag]
	Comment 11 • 7 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.

	Kris Maglione [:kmag]
	Comment 12 • 7 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.

	[:fabrice] Fabrice Desré
	Comment 13 • 7 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?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 14 • 7 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?

	Tim Nguyen :ntim
	Comment 15 • 7 years ago

Try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=11c4e1bc3d03

	Kris Maglione [:kmag]
	Comment 16 • 7 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.

	[:fabrice] Fabrice Desré
	Comment 17 • 7 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.

	Caitlin Neiman [:caitmuenster]
	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

	Caitlin Neiman [:caitmuenster]
	Comment 19 • 7 years ago

This idea has been approved, but more internal discussions will be needed to figure out how to implement it.

	Tim Nguyen :ntim
	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 ?

	Olli Pettay [:smaug][bugs@pettay.fi]
	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.)

	Olli Pettay [:smaug][bugs@pettay.fi]
	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"

	Olli Pettay [:smaug][bugs@pettay.fi]
	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

	Boris Zbarsky [:bzbarsky]
	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....

	Tim Nguyen :ntim
	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.

	Boris Zbarsky [:bzbarsky]
	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.

	Andy McKay
	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).

	dw-dev
	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?

	Andy McKay
	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.

	dw-dev
	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?

	Boris Zbarsky [: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.

	[:fabrice] Fabrice Desré
	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).

	Boris Zbarsky [:bzbarsky]
	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.

	Tim Nguyen :ntim
	Comment 40 • 6 years ago

Looks like this is blocked until the spec stuff is sorted out.

	Fred Brunner
	Comment 41 • 6 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.

	Shane Caraveo (:mixedpuppy)
	Comment 42 • 6 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.

	Shane Caraveo (:mixedpuppy)
	Comment 43 • 6 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>`).

	[:fabrice] Fabrice Desré
	Comment 44 • 6 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.

	Shane Caraveo (:mixedpuppy)
	Comment 45 • 6 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.

	ExE Boss
	Comment 46 • 6 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.

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

	ExE Boss
	Comment 49 • 6 years ago

Changing the URL to the `<iframe mozbrowser>` documentation on MDN.