Closed Bug 1006808 Opened 10 years ago Closed 10 years ago

Open URLs with web activities

Categories

(Firefox OS Graveyard :: Gaia::Search, defect)

x86
macOS
defect
Not set
normal

Tracking

(b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S2 (23may)
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: kgrandon, Assigned: daleharvey)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

Currently URL submissions and links are opened in a wrapper window using window.open(). Now that we have the search app opened from the homescreen, it makes sense to open these links using a web activity so they open in the browser in the 2.0 release. This will also work for 2.1 as activities will be handled by the system app and opened in a wrapper window.

We can also consider moving the submission part of the URL to the system app, but that might mean duplicate code as we would continue to need some way of doing this from the search app.
Hey Dale - this is something we need for homescreen. Would you be interested in taking it? Thanks!
Flags: needinfo?(dale)
I would prefer not to rely on the search app for something as simple as loading a URL. It would be great if the web activity was fired by the system app.
I can take, but a little confused at this, what do you mean by url submissions / links, do you mean the links we open from the search app? or from other apps?

If they are other apps, why do we want the search app to be involved in opening them? the search app may or may not be started, and the search app only does a window.open itself to open new app frames

I think I am missing something here
Flags: needinfo?(dale) → needinfo?(kgrandon)
I think Kevin means:

1) When you hit enter after typing a URL in Rocketbar
2) When selecting a Rocketbar result

For 1, I think the system app should detect that it's a URL and fire a view URL web activity to open it in the browser app (until we use the system browser). This shouldn't need to rely on the search app to work.

For 2, I think we actually still want to use window.open because the results are all e.me results which should open in a WrapperWindow, except for maybe the Google link if that still exists, which in the absense of a Google app should probably open in the browser. The WrapperWindow used by e.me apps in 1.4 is currently different to the one used by homescreen bookmarks. I'm guessing e.me results should open in the e.me version of WrapperWindow, but I don't know how that works.
Oh right, apologies - E.me results should definitely use window.open. Thanks Ben.
Flags: needinfo?(kgrandon)
Heh sorry, still being slow here, rocketbar / search app is 2.1, we want to be opening links in the 'system browser', (which is via window.open), why do we want to be opening stuff in the browser app at any time?

I think I may me being confused as to what is being released when
(In reply to Dale Harvey (:daleharvey) from comment #6)
> Heh sorry, still being slow here, rocketbar / search app is 2.1, we want to
> be opening links in the 'system browser', (which is via window.open), why do
> we want to be opening stuff in the browser app at any time?
> 
> I think I may me being confused as to what is being released when

In bug 1003960 Kevin implemented a kind of baby Rocketbar that extends the grown up Rocketbar, and is intended to ship in 2.0 with the new homescreen app (so that we don't have to re-implement e.me in the new homescreen and can use the search app instead).

In this bug Kevin is asking that typing a URL into the baby Rocketbar should launch the current browser app via a web activity (as there won't be a full system browser in 2.0), though I'm not sure whether we have a UX spec that defines that behaviour yet.
ok that makes sense, thanks for the clarification, will do that
Assignee: nobody → dale
There are other applications within the search app that may or may not want to open their urls in a browser tab, while we will very likely disable places, keeping it in the search app keeps the logic consistent and future compatible.

It would be nice to be consistently using window.open vs mozActivity, however thats an issue with 2.0 supporting both methods, we can remove it in 2.1

I think the existing tests cover this, but gimme a heads up if theres anything you think should be tested.
Attachment #8420433 - Flags: review?(kgrandon)
Comment on attachment 8420433 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19126

So on reading https://bugzilla.mozilla.org/show_bug.cgi?id=941035 I think ben is right and we will have to open urls directly entered in the rocketbar, clearing and will do a patch that covers both
Attachment #8420433 - Flags: review?(kgrandon)
Depends on: 941035
Fixed in https://github.com/mozilla-b2g/gaia/commit/c123449a625878bf69aa2b8a0d611db4484d4d5f
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S2 (23may)
Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: