Closed
Bug 934631
(browser-window)
Opened 11 years ago
Closed 6 years ago
[Window Management] Implement BrowserWindow
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P2)
Tracking
(tracking-b2g:backlog)
RESOLVED
WONTFIX
tracking-b2g | backlog |
People
(Reporter: alive, Unassigned)
References
Details
(Whiteboard: [systemsfe])
Attachments
(1 file)
34.95 KB,
image/png
|
Details |
This would be similar to PopupWindow/WrapperWindow, but it's invoked from Rocketbar and has all chrome UI natively.
Reporter | ||
Updated•11 years ago
|
Blocks: task-manager
Reporter | ||
Updated•11 years ago
|
No longer blocks: task-manager
Reporter | ||
Updated•11 years ago
|
Alias: browser-window
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?
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
Reporter | ||
Comment 3•11 years ago
|
||
It looks like we finally could merge popup and browser but I'm not 120% sure..
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?
Flags: needinfo?(alive)
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?
Assignee: nobody → bfrancis
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.
Flags: needinfo?(alive)
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
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.
Updated•10 years ago
|
blocking-b2g: --- → backlog
Priority: -- → P2
Whiteboard: [systemsfe]
Assignee | ||
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•9 years ago
|
Assignee: bfrancis → nobody
Comment 9•6 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•