As a user I want to launch a site from its pin badge so I can use it again.

A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/95569424

Assuming this is talking about the homescreen. Ben, similar to bug 1169006, is this already done?

I don't think this one is quite done yet, we need to implement the behaviour which will open the most recently used existing window at a URL within the scope of the site, rather than always creating a new one. We also need to change the behaviour of the browser icon which may also fall under this bug.

Comment on attachment 8649941 [details] [gaia] albertopq:1169010-launch-pinned-site > mozilla-b2g:master This is looking good, I've left some comments on GitHub to discuss further. From Foxfooding and UX comments I think this is the behaviour that people want. My one concern is that two pinned sites which share the same hostname may display some odd behaviour - e.g. If you've bookmarked both google.com/calendar and google.com/maps but neither specifies a scope then tapping the icon for one will reuse a window of the other if already open. It does also make it harder to get back to the start URL of a site, but I think people are saying they prefer that windows are re-used. I think most of this is going to be safe to land, although the bit which sets the pinned state on a window when launching a bookmark might be a bit confusing outside of the context of the rest of the Pin the Web features.

Comment on attachment 8649941 [details] [gaia] albertopq:1169010-launch-pinned-site > mozilla-b2g:master It makes sense to leave the changes to the chrome to bug 1168962. I undid all the changes related to that and manually pinned the sites in the UI tests for testing the browser functionality for now. Thanks!

Comment on attachment 8649941 [details] [gaia] albertopq:1169010-launch-pinned-site > mozilla-b2g:master Thanks Alberto, r+ with a couple of nits on GitHub to address first. This is going to introduce some slightly weird behaviour until bug 1168962 lands. If you launch a bookmark and then navigate it away from its initial URL, then both the bookmark icon and the browser icon will re-open the window. This is because bug 1168962 will complete the logic to know when a page is part of a pinned site or not and properly transform a pinned window between pinned/unpinned state. Hopefully this won't be too noticeable.

master: https://github.com/mozilla-b2g/gaia/commit/37e8857054fd4cbcb86484ea55c8afe4e7fc584f

If I understand correctly, when I do this: - Tap on Browser app on homescreen - Open a url/type in a url and press enter, e.g: http://nu.nl - Tap on the home button to get back to the homescreen - Tap on Browser app on homescreen again Old result: - New browser window with a new tab would be opened. New result: - Exiting browser window is opened, with the url http://nu.nl That is what this pull request has changed in here, right? It has changed this behavior, right?

Another question: window.wrappedJSObject.Service.query('getTopMostWindow').manifestURL returns 'app://search.gaiamobile.org/manifest.webapp' on a new tab page, but it gets null after browsing to some random url. However, the .origin property stays app://search.gaiamobile.org in both cases. Is that expected behavior? Why does the .manifestURL property suddently get null after browsing to some url?

Hi Martijn, Yes, that's almost correct. Tapping on the browser will reopen the last unpinned page. That means that if you open a URL, and then pin it, opening the browser will result on the old behavior (opening a new window). You can find the specification attached to this bug (https://bug1169010.bmoattachments.org/attachment.cgi?id=8644345). (In reply to Martijn Wargers [:mwargers] (QA) from comment #11) > If I understand correctly, when I do this: > - Tap on Browser app on homescreen > - Open a url/type in a url and press enter, e.g: http://nu.nl > - Tap on the home button to get back to the homescreen > - Tap on Browser app on homescreen again > > Old result: > - New browser window with a new tab would be opened. > > New result: > - Exiting browser window is opened, with the url http://nu.nl > > That is what this pull request has changed in here, right? It has changed > this behavior, right?

(In reply to Martijn Wargers [:mwargers] (QA) from comment #12) > Another question: > window.wrappedJSObject.Service.query('getTopMostWindow').manifestURL returns > 'app://search.gaiamobile.org/manifest.webapp' on a new tab page, but it gets > null after browsing to some random url. However, the .origin property stays > app://search.gaiamobile.org in both cases. > Is that expected behavior? > Why does the .manifestURL property suddently get null after browsing to some > url? I'm not sure about the expected behavior here. Ben is probably the right person to answer this.

Alberto, another thing I noticed: - Open a browser window, go to some url, e.g.: "http://nu.nl" - Open a new window, you get a the newtab page with "Top Sites" and "New private window" button - Touch the home button - Tap on the Browser icon Now you get back to the browser window with the "http://nu.nl" page instead of the newtab page. Is that expected behavior?

I guess we should go back to the last unpinned page (which is the new browser window). Could you please file a bug? Thanks!

(In reply to Alberto Pastor [:albertopq] from comment #16) > I guess we should go back to the last unpinned page (which is the new > browser window). Could you please file a bug? Thanks! I filed bug 1208263 for this now.