User Story: As an app developer I want to tell the browser to view a URL. Acceptance Criteria: Functionality should match existing Browser functionality unless described otherwise in UX spec. Note: This bug is mainly to ensure this use case is already satisfied after the Browser becomes part of System.

This was implemented at some point in time for bug 946452.

I don't understand why you think this is implemented. For it to be implemented, surely the system app manifest would have to contain: "activities": { "view": { "filters": { "type": "url", "url": { "required":true, "pattern":"https?:.{1,16384}", "patternFlags":"i" } } } } as the browser app does, and handle that web activity. If we are going to use an alternative method of telling the browser to view a URL then other apps surely need updating to use that new method?

Yes, this is correct - I was misunderstanding the original description. Thanks for reopening.

Taking this.

When you think about it, we really shouldn't need a view URL web activity, it's kind of silly. You should just be able to use a hyperlink with target=blank or call window.open. The problem is that currently if you do that from an app it will create one and only one additional window as an overlay. In the long term I think we should fix that to create a new browser window if the URL is from a different origin and a new sheet for same origin links once we have sheets. For the prototoype I'm not sure there's a simple way of doing that so we may just have to add support for the web activity to the system app. Assuming the system app can consume web activities... What approach were you thinking of taking Kevin?

(In reply to Ben Francis [:benfrancis] from comment #6) > What approach were you thinking of taking Kevin? This one :) I think this is sold enough for now, and is a pretty good transition to using window.open() if we want to in the future as it supports both paths. I'm not sure if window.open() is the right way to go as right now we would require the open-remote-window permission, but perhaps we could relax that? Anyhow, I feel that we may be able to go with this approach for user testing.

Overwriting pull request so it will run on travis.

The first part has landed in master: https://github.com/mozilla-b2g/gaia/commit/b7dd8667cbcdaff78861c77e4d2a9f6e6f45edc8 I am also renaming the bug so it is very clear that this is in the rocketbar branch, but not in master. The bug will remain open, so this will make it easy to identify which bugs we need to take action on still. Will be removing the tag when we are ready to merge to master.

Er, did not land in master, but rocketbar :)

This will be implemented in bug 962655 instead.

Again, sorry to bang on about this but these user story bugs track individual use case IDs (see the whiteboard) which correspond to Product's backlog and need to be verified after being closed. Merging them all into one bug will make that difficult, so let's mark the bug where you want to do the work as blocking this one rather than lose that information.

(In reply to Ben Francis [:benfrancis] from comment #13) > Again, sorry to bang on about this but these user story bugs track > individual use case IDs (see the whiteboard) which correspond to Product's > backlog and need to be verified after being closed. Merging them all into > one bug will make that difficult, so let's mark the bug where you want to do > the work as blocking this one rather than lose that information. Sure thing! Sorry, I'm not familiar with the SystemsFE process. I will setup a meeting with Candice so I can understand better in the future. For now I will try to just setup blocking bugs against these user story bugs, so that make things more clear. I will land the dependent bug, then we can verify this one.

No patch in this bug, and bug 959353 is only about getting things landed in master, so unblocking.

Estimating as 3 points, mainly due to the need for build-time configuration of whether the system app or browser app handles view URL web activities. Alternatively we could go the window.open route.

fixed in a combination of bugs, ultimately https://bugzilla.mozilla.org/show_bug.cgi?id=941175

Test cases for the browser app are being used: https://moztrap.mozilla.org/manage/case/9276/ https://moztrap.mozilla.org/manage/case/7206/