Closed Bug 1122171 (rocketbar-global-search) Opened 5 years ago Closed 2 years ago

Rocketbar global content search

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kgrandon, Unassigned)

References

Details

User Story

We would like to be able to search content across the OS.
No description provided.
Depends on: 1122174
Depends on: 1122175
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
There are still a few architecture questions we need to figure out here.

1 - Suggesting a common URL pattern for objects in gaia. I need to check and see how hashchange events are handled in gaia, and if we could rely on those to store history. If not we may need to move to a full sheets model, or possibly use the querystring? E.g., app://origin/page.html?/controller/view/id

2 - Storage of history content and how to search it. Currently we use places.js to add items to the history based on applocationchange or apptitlechange. To surface history results we search the URL and the title of the history item, but we currently don't search any "body" content. If a user receives a sms message, I assume we should surface that message if we can match some content within the body. I wonder if we allow the app to choose what to index, or if we could simply store the entire innerHTML blob of the page.
Dale/Ben - any thoughts on comment 1?
Flags: needinfo?(dale)
Flags: needinfo?(bfrancis)
1 - I am fairly sure we dont get hashchange events over the browser api but it will be possible to do. I dont expect we will be able to get any concencus on a url format but to add hashchange to the browser api and assume applications to use stateful urls seems like the right way to work for me.

2 - Storing the entire innerHTML for every url change sounds unfeasible, I expect we need to provide the apps the ability to give us content to index and carefully manage it
Flags: needinfo?(dale)
Sounds good. I do think there is a lot of benefit in proposing a few simple rules to follow for URLs, mostly for consistency sake and lowering the barrier to hacking on different apps. If all apps use similar routing for example, it's much easier to dive into that code and figure out what's going on.

I'll spend a little bit of time drafting some rules and getting feedback from people.
If the goal really is global content search, it seems like the right way, web-standards-wise, would be to run with the ServiceWorker execution model and define some standard hookup that lets apps indicate they can provide global search functionality.  Because we can't efficiently ask all the apps at once, the rocketbar would query them in some order based on how often the apps are used, how recently they were used, and how often their results are the ones chosen.  If we care less about standardizing this, the shared IndexedDB databases that are supposed to replace DataStorage seem workable.

The hashchange stuff sounds like doing more of an "awesomebar that indexes the page content the user views".  This seems advisable given the limited resources of Firefox OS devices to date since it doesn't require spinning up arbitrarily large amounts of application code for potentially many applications.  I think full-text indexing of the page is beyond us for both quality and device resource reasons at this time, but we could certainly do something standardsy by just scraping document.title and the value of the document meta "keywords" as standardized at http://www.w3.org/TR/html5/document-metadata.html#standard-metadata-names.  (Or some other meta field, there are apparently a jillion of them registered at https://wiki.whatwg.org/wiki/MetaExtensions.)

The title is already something exposed to mozbrowser, and arguably the contents of the keywords or other meta fields are also something intended to be exposed to the browser, so there isn't as much potential concern about privacy or security impact there.  This should also allow the rocketbar or system app to be relatively efficient about getting its data since the notifications could be event-driven based on changes in those meta fields.  This is important since many apps already are having trouble meeting various performance goals and having an external actor periodically reach in and serialize the entire DOM with innerHTML would not help that.
Firstly, this is a feature I would love to see (it was the original vision for Rocketbar that Gordon and I started with), and I completely agree with the general direction of having URLs for each piece of data (like an SMS), and navigating to that URL when the user clicks a result.

Kevin wrote:
> 1 - Suggesting a common URL pattern for objects in gaia

This doesn't sound like a solution which would scale to the whole web, so I don't think it's worthwhile pursuing.

> I need to check and see how hashchange events are handled in gaia

I thought they fired a locationchange event, but I might be wrong about that.

> 2 - Storage of history content and how to search it

This sounds like a better approach. The whole reason the Browser API was invented was to prevent the browser app code from accessing the content inside the iframe so I don't think being able to access and store the whole body of every web page you visit using the Browser API is a great idea. However, I have been thinking about something similar along these lines...

What if web apps exposed pieces of data they wanted to be searchable by marking up that data using some basic extensible semantic markup like Microformats http://microformats.org/wiki/microformats-2

When Gecko comes across a piece of semantic metadata in a web app or web page you visit, we fire an event on the Browser API which allows us to store that data alongside the page's URL in the Places database. This data could then be surfaced as "cards" in the Rocketbar search results with a link back to the page they came from. This is just one use case being discussed for the Web Cards concept https://etherpad.mozilla.org/webcards in the More Webby Firefox OS ideation group https://etherpad.mozilla.org/more-webby-firefox-os for v3.

Andrew wrote:
> If the goal really is global content search, it seems like the right way, web-standards-wise, would be to run with the ServiceWorker execution model and define some standard hookup that lets apps indicate they can provide global search functionality.

This sounds interesting. I previously looked into whether Service Workers could be used as a replacement for our Inter-app Communication API as a sort of offline REST API for apps, but soon discovered that the same-origin restrictions of Service Workers make that impossible. Can you explain a bit more how this could work?

> the shared IndexedDB databases that are supposed to replace DataStorage seem workable.

Ooh, where can I read more about this?

> The hashchange stuff sounds like doing more of an "awesomebar that indexes the page content the user views".  This seems advisable given the limited resources of Firefox OS devices to date since it doesn't require spinning up arbitrarily large amounts of application code for potentially many applications.  I think full-text indexing of the page is beyond us for both quality and device resource reasons at this time, but we could certainly do something standardsy by just scraping document.title and the value of the document meta "keywords" as standardized at http://www.w3.org/TR/html5/document-metadata.html#standard-metadata-names.

It would be cool if meta tags were enough, but I suspect we need more than that. I think we need a way of indexing structured metadata from a web page to be presented in a standard format in search results. I think Microformats an example of how this could be done, and the canonical JSON encoding of the data types defined in Microformats 2 lends itself well to being stored in the Places database and rendered into a "card" in search results.

The Backlog to the Future v3 ideation group (including Jonas) also posted a related concept called "The Entire History of You(r Web)" https://slack-files.com/T033ZPYCR-F03A72GRX-58a8b4b44a There's some discussion here https://fxos-v3.slack.com/files/jaime/F03A72GRX/theentirehistoryofyourweb_firefoxosv3_20150106.pdf (sorry this is link is probably private, I didn't choose for us to use Slack).

I would really encourage you to contribute these ideas to either the Backlog to the Future group (The Entire History of You(r Web) concept) or the More Webby Firefox OS group (Web Cards concept) to get help get those ideas considered for the v3 roadmap. There are currently 21 lightning talks scheduled for this week with people pitching v3 ideas like these so these concepts could do with your support.
Flags: needinfo?(bfrancis)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.