(inactive after 6/18) Alive Kuo [:alive] Reporter
	Description • 11 years ago

This would be similar to PopupWindow/WrapperWindow,
but it's invoked from Rocketbar and has all chrome UI natively.

	Ben Francis [:benfrancis]
	Comment 1 • 11 years ago

What is the difference between WrapperWindow and BrowserWindow?

(In reply to Alive Kuo [:alive][NEEDINFO][OOO:12/24-1/4] from comment #0)
> This would be similar to PopupWindow/WrapperWindow,
> but it's invoked from Rocketbar and has all chrome UI natively.

A BrowserWindow could be invoked from a bookmark too, just like a WrapperWindow. All AppWindows and WrapperWindows will have the Rocketbar chrome present. All WrapperWindows/BrowserWindows and some AppWindows may have the navigation bar (AppChrome) at the bottom, but that can be injected.

If AppWindow becomes BaseWindow then perhaps WrapperWindow should become BrowserWindow and AppChrome should become BrowserChrome?

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 2 • 11 years ago

AFAIK, now the way bookmark works is just to open the wrapper. SO I will think WrapperWindow = BrowserWindow, yes.
Also I am thinking about rename appChrome too. appXXXXX is not a good naming. See
https://bugzilla.mozilla.org/show_bug.cgi?id=938972
https://bugzilla.mozilla.org/show_bug.cgi?id=949864

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 3 • 11 years ago

It looks like we finally could merge popup and browser
but I'm not 120% sure..

	Ben Francis [:benfrancis]
	Comment 4 • 10 years ago

Hi Alive, I would be interested in helping with this if you think it's still needed?

Perhaps you could mentor me to help me split parts of AppWindow out into BrowserWindow and perhaps then split parts of Rocketbar into SearchWindowManager and AppChrome into BrowserChrome?

	Ben Francis [:benfrancis]
	Comment 5 • 10 years ago

Also, do you think that BaseWindow should eventually be split out from AppWindow so that an AppWindow can be a BaseWindow with an app manifest and optional AppChrome and a BrowserWindow can be a BaseWindow with BrowserChrome?

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 6 • 10 years ago

Hmm, I am not sure if BrowserWindow is still necessary.
From the experience to now, I don't feel it's a big pain to have new AppWindow() everywhere and check by AppWindow.prototype.isBrowser().

BaseWindow -> AppWindow (no appChrome by default)
           -> BrowserWindow (native chrome)
sounds reasonable though.

Also note:
* Do you want a different event prefix for browserWindow? Now we are using app* everywhere. We need to change a lot if there is a browser*
* Semantic issue.. will we deprecate the naming "Browser" someday? We are making a lot of effort to erase the boundary between apps and web pages. Or will we transfer from browser to webview someday and it'd be strange to have the naming brower in the class?

I won't object if you are willing to work on;
I believe we need to clean current appWindow since it's a little heavy now.
and this one might be one of the ways to clean it up. Just worry that you will be overloaded by this change.

	Ben Francis [:benfrancis]
	Comment 7 • 10 years ago

Thanks for the reply Alive. Here's the way I see things going in the future based on emerging web standards. Let me know what you think.

I do think there's value in separating BrowserWindow out of AppWindow, not just to get rid of all the isBrowser() checks, but because I think if we introduce App Scope [1] in 2.2 then app windows may behave quite differently to browser windows.

An AppWindow would be limited to a particular URL scope defined by a "scope" property in an app manifest [2]. By default the scope is the origin of the manifest. Attempting to navigate the AppWindow outside of that URL scope would instead open a new BrowserWindow or open in another app if the URL falls under its scope.

Also, if we implement [3] the displayModes [4] proposed in the W3C Web Manifest specification then then the following mappings might make sense:

fullscreen - AppWindow launched in full screen mode limited to the app scope
standalone - AppWindow with no AppChrome limited to the app scope
minimal-ui - AppWindow with AppChrome limited to the app scope
browser - BrowserWindow (including BrowserChrome) not limited to any scope

Currently the main differences between "app chrome" and "browser chrome" in Gaia are that the browser chrome has an overflow menu and when the Rocketbar is focused the URL is shown.

With regards to <webview> [5], I would eventually like to see <iframe mozbrowser> become <webview> [6] and <iframe mozbrowser mozapp=""> to become <webview manifest="">. Then we might want to change BrowserFrame to Webview. An AppWindow could have a Webview which is limited to a particular URL scope defined by the manifest at the URL referenced in its manifest attribute. A BrowserWindow could have a Webview with no manifest attribute set, so it is not limited to any URL scope.

I think the name "browser" in "BrowserWindow" comes more from the "browser" display mode in the Web Manifest. I'm not sure about app* vs browser* prefixes for events, I would need to investigate that further.

It's true that in Haida we are blurring the boundaries between web apps and web sites to make it more seamless navigating between the two, but with App Scope and Web Manifest we are also more clearly defining a web app as a "slice" of the web, defined by URL scope, which is managed separately from the browser. I hope to write a blog post about this soon.

I expect the changes I describe here could take a long time, but I think we can do small pieces at a time and with your help I think I could try to take a first step in this bug?


1. https://bugzilla.mozilla.org/show_bug.cgi?id=1038833
2. http://html5doctor.com/web-manifest-specification/
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1003890
4. http://w3c.github.io/manifest/#display-modes
5. http://benfrancis.github.io/webview/
6. https://bugzilla.mozilla.org/show_bug.cgi?id=738172

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 8 • 10 years ago

(In reply to Ben Francis [:benfrancis] from comment #7)
> Thanks for the reply Alive. Here's the way I see things going in the future
> based on emerging web standards. Let me know what you think.
> 
> I do think there's value in separating BrowserWindow out of AppWindow, not
> just to get rid of all the isBrowser() checks, but because I think if we
> introduce App Scope [1] in 2.2 then app windows may behave quite differently
> to browser windows.

I think we still need a method for event handler to tell the window is a browser or an app,
but this might be a minor issue.
I know you are working on app scope stuff and are very curious to hear from you how this will be implemented (in gecko/gaia)

> 
> An AppWindow would be limited to a particular URL scope defined by a "scope"
> property in an app manifest [2]. By default the scope is the origin of the
> manifest. Attempting to navigate the AppWindow outside of that URL scope
> would instead open a new BrowserWindow or open in another app if the URL
> falls under its scope.

Yes makes sense.

> 
> Also, if we implement [3] the displayModes [4] proposed in the W3C Web
> Manifest specification then then the following mappings might make sense:
> 
> fullscreen - AppWindow launched in full screen mode limited to the app scope
> standalone - AppWindow with no AppChrome limited to the app scope
> minimal-ui - AppWindow with AppChrome limited to the app scope
> browser - BrowserWindow (including BrowserChrome) not limited to any scope
> 
> Currently the main differences between "app chrome" and "browser chrome" in
> Gaia are that the browser chrome has an overflow menu and when the Rocketbar
> is focused the URL is shown.
> 
> With regards to <webview> [5], I would eventually like to see <iframe
> mozbrowser> become <webview> [6] and <iframe mozbrowser mozapp=""> to become
> <webview manifest="">. Then we might want to change BrowserFrame to Webview.
> An AppWindow could have a Webview which is limited to a particular URL scope
> defined by the manifest at the URL referenced in its manifest attribute. A
> BrowserWindow could have a Webview with no manifest attribute set, so it is
> not limited to any URL scope.

+1 for webview change, I designed the browserMixin and browserFrame departure from appWindow just because I know mozbrowser iframe will be transformed someday.

> 
> I think the name "browser" in "BrowserWindow" comes more from the "browser"
> display mode in the Web Manifest. I'm not sure about app* vs browser*
> prefixes for events, I would need to investigate that further.
> 
> It's true that in Haida we are blurring the boundaries between web apps and
> web sites to make it more seamless navigating between the two, but with App
> Scope and Web Manifest we are also more clearly defining a web app as a
> "slice" of the web, defined by URL scope, which is managed separately from
> the browser. I hope to write a blog post about this soon.
> 
> I expect the changes I describe here could take a long time, but I think we
> can do small pieces at a time and with your help I think I could try to take
> a first step in this bug?
> 

Sure, let's start it in v2.2? if you'd like to work on.

	BMO Automation
	Comment 9 • 6 years ago

Firefox OS is not being worked on