I think this behaviour was changed in bug 1055761. There is code which switches to an existing app window rather than launch a new one when you try to open a new window with the same URL. This used to apply to wrapper windows too, but was removed for browser windows in the system browser.
The problem was that the code would switch to any window which was *created* at that URL, but wasn't necessarily currently at that URL. This isn't noticeable for single page apps which stay at their launch_path, but for browser windows which are commonly navigated away from their initial URL it can mean that trying to open a window at mozilla.org could switch to a window at twitter.com for example (see the bug STR). If we want to re-instate this behaviour then we need to make sure that it only happens when the URL is an exact match. Matching by origin probably isn't a good idea if we're going to support multiple apps per origin. App Scope (meta bug 1038833) will implement behaviour similar to this for installed apps by registering a URL scope in the app registry which a particular app is responsible for so the window manager knows which app to open a given URL in. This will allow multiple apps per origin and app and non-app content on the same origin. Also, I'm working on modifying "add to homescreen" as part of the "Web Manifest" work so you can dynamically install an app into the app registry by doing "add to homecreen" on a web page (terminology TBD) which sounds a bit like the "pin as an app" feature you're asking for. Currently this is only for pages which reference a web manifest in a link relation with a "fullscreen", "minimal-ui" or "standalone" display mode. We could consider extending this behaviour to web pages which specify the (currently proprietary and not widely used) mobile-web-app-capable meta tag and an application-name meta tag as a hint that they will work well as a standalone app. Providing the option to "pin as an app" on any web page is a step further than this, and something which might be cool to do. We'd have to make some assumptions which could make it a footgun for users though. I definitely don't think we should just change the behaviour of all browser windows to switch to an existing browser window if you try to open a window at a URL in the same origin. I wouldn't expect http://google.com to switch to my browser window at http://google.com/calendar and navigate away from my calendar for example. On Wed, Oct 22, 2014 at 9:59 AM, Dale Harvey <[email protected]> wrote: > Agreed, its bitten me a lot of times opening a ton of extra browser > windows for the same session > > However alternatively, its actually a surprisingly useful feature, I often > want to for example, open a route on my map, then not touch that but also > have a zoomed in version for actual navigation. > > I would love for us to have these use cases and behaviours matched across > apps and homescreen bookmarks, one suggestion would be homescreen bookmark > + apps both launch existing instances as long as they are within the same > origin, and long click on either provides the ability to open a new > instance (this can only work in the rocketbar since we use longpress for > reorder on the homescreen) > > Some consistent behaviour would be very nice though > > > On 22 October 2014 02:44, Thinker K.F. Li <[email protected]> wrote: > >> For now, browser app has a feature "Add to home screen." >> But, it would open a new process/session for everytime launching the URL >> from home screen. It causes some problems in UX. >> It is fine for static pages, but for services like gmail, forum, ..., >> etc., with no WebApp, you possibly like to stay in the same session. >> >> It is exactly the same as the old behavior of "Add to home screen." >> I think we should bring it back as a new feature. >> >> -- >> Sinker >> -- >> 天教懶漫帶疏狂 >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
