892020 - Keep the webapps registry in sync with applications installed

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Web Apps, defect, P2)

Description

[Marco Castelluccio [:marco]]

It would be good to fix this in a way that also frees Firefox from the need to know installation directories (so we won't break old installations if we'll change the format of directory names and we'd remove the only contraint for multiple-apps-per-origin in the desktop webrt).

Comment 1

[Marco Castelluccio [:marco]]

We need to keep in mind that:
1) If Firefox is running, there could be concurrency issues if we directly access the registry files.
2) If Firefox is running, we also need to keep the DOMApplicationRegistry variables up to date.
3) Probably the webapps registry (plain files at the moment) will use indexedDB.

Comment 2

[James Hugman [:jhugman] [@jhugman]]

I'm not entirely sure what is being asked for. This is desktop?

I don't especially like the one-app-per-origin either.

Comment 3

[Marco Castelluccio [:marco]]

(In reply to James Hugman [:jhugman] [@jhugman] from comment #2)
> I'm not entirely sure what is being asked for. This is desktop?

Yes, on desktop the webapps registry could end up being unsynced with the installed applications (because you don't uninstall apps through Firefox but through "native" means).

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

This sounds like bug 890062 on Android

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #1)
> We need to keep in mind that:
> 1) If Firefox is running, there could be concurrency issues if we directly
> access the registry files.
> 2) If Firefox is running, we also need to keep the DOMApplicationRegistry
> variables up to date.
> 3) Probably the webapps registry (plain files at the moment) will use
> indexedDB.

Fabrice has suggested reimplementing the registry store with IndexedDB, but I'm not sure that would solve the concurrency problem.  I've considered reimplementing it with SQLite, which would solve that problem; but it may have other implications.

It isn't absolutely necessary for all three runtimes to share one registry store implementation.  For example, we could use IndexedDB in FxOS and SQLite on desktop.  And the constraints do vary, since apps on FxOS share a process and profile, while those on desktop each get their own.  Nevertheless, I would prefer to reuse the same implementation across the three runtimes.

An alternative to reimplementing the store would be to implement a "shared data service" that gives both Firefox and webapp processes safe access to the store.  bsmedberg has previously suggested doing something like that, not only for the webapp registry but also for other profile data that it is useful to share across processes (including perhaps the Windows classic and Metro browsers).

Another alternative would be to reuse Gecko's existing support for "remote control" <http://www-archive.mozilla.org/unix/remote.html> to query the Firefox process for registry information, starting the process in a headless mode and then shutting it down afterward if it isn't currently running.  That would be easier to implement than a shared data service, but remote control doesn't seem to be used much; and the last time I tested it, I couldn't get it to work on Mac; so I'm not sure how reliable it is.

Comment 6

[Marco Castelluccio [:marco]]

Another problem to keep in mind is that on Mac OS X we don't have an uninstaller, so we don't know when an application gets uninstalled.
Maybe we could get a notification, but that would work only while Firefox is running.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #6)
> Another problem to keep in mind is that on Mac OS X we don't have an
> uninstaller, so we don't know when an application gets uninstalled.
> Maybe we could get a notification, but that would work only while Firefox is
> running.

Yes, we'll have to do something different on Mac.  The OS does track uninstallation, for Spotlight and other Mac services, and considers an app uninstalled when its package is put into the Trash.  So it should be possible to query it for the status of an app, lazily, when the registry is first queried for that status.

Comment 8

[Benjamin Smedberg]

Other than being unhappy that we *have* a webapps registry in the first place (apart from keeping data in the store app itself), I don't have great new thoughts about this. I do prefer querying a central service rather than trying to share data on-disk, partly because file corruption is easy to cause and debugging it is very hard.

Comment 9

[[:fabrice] Fabrice Desré]

(In reply to Benjamin Smedberg  [:bsmedberg] PTO 8-Aug until 18-Aug, workweek high latency 19-Aug through 23-Aug from comment #8)
> Other than being unhappy that we *have* a webapps registry in the first
> place (apart from keeping data in the store app itself), I don't have great
> new thoughts about this. I do prefer querying a central service rather than
> trying to share data on-disk, partly because file corruption is easy to
> cause and debugging it is very hard.

I don't understand what you mean by "keeping data in the store app itself", since we can install apps from any random website. How could we not have a webapps registry on the client?

I agree that we need something storage-agnostic and not share an on-disk specific format.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.