Closed Bug 775847 Opened 12 years ago Closed 11 years ago

WebApps code should allow more than one webapp per origin

Categories

(Core Graveyard :: DOM: Apps, defect)

Product:
Core Graveyard
Component:
DOM: Apps
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:-)

Status:
RESOLVED DUPLICATE of bug 778277
Project Flags:
blocking-basecamp -

People

(Reporter: mounir, Unassigned)

Details

This limitation has no sense with the B2G security model. We should not have arbitrary limitations like this.

We could add new pre-installed apps in the test profile too (see bug 770894).
CCing Anant since I think he said this may cause issues with receipt verification flows.
I think we should take a decision whether we want to have this or not for basecamp. The security model can handle that. They should just have different manifest URLs. However, it seems that WebApps code isn't ready for this.
blocking-basecamp: --- → ?
Component: General → DOM: Mozilla Extensions
Component: DOM: Mozilla Extensions → General
Product: Core → Web Apps
Version: Trunk → unspecified
Jonas proposed doing this in a conversation on dev-webapps in April and May.  Unfortunately, only 18/30 messages in that conversation are archived <https://groups.google.com/forum/#!topic/mozilla.dev.webapps/lILc00-owaQ>, and the missing ones include the last three messages he sent in the thread, but his proposal in the final message was:

  to determine which app a given URL belongs to, we simply look at the window/tab
  which the URL is currently running in.  The app used to start that window/tab is
  what determines the app.
In favor of basecamp- - this is large architectural change across the board on multiple platforms and marketplace. I think we can live without this for v1 of b2g unless there's some really strong reason from product for having this.
(In reply to Jason Smith [:jsmith] from comment #4)
> In favor of basecamp- - this is large architectural change across the board
> on multiple platforms and marketplace. I think we can live without this for
> v1 of b2g unless there's some really strong reason from product for having
> this.

There's a strong reason to make it clear that no code should expect one app per origin anymore, and the sooner the better. I would not call that a "large architectural change" either. The trickiest part is the security model and the mozapp attribute pieces but they are ok.

The API itself needs no changes either afaict, so what's left to update is:
- some parts of the DOM registry implementation (I know what to do).
- webrt support?
- app sync?
- marketplace?

Remember that this limitation has been a major issue for small developers and I care more about them than big properties that can manage subdomains.
Note that we'll need to update the FAQ "Can I have more than one app at my origin?" if/when we do this:

https://developer.mozilla.org/en/Apps/FAQs/About_app_manifests
It may not be a large architectural change, although it is definitely a change in the architecture and by no means trivial. All code right from the beginning of the Apps project has been written with this assumption in mind.

I agree that no new code should be written that makes this assumption, but re-writing all the existing code to lift the restriction is likely going to be more than a couple days of work.

The dates are quite aggressive for basecamp, but is is possible that with combined resources we may be able to pull it off. However, my vote is still for basecamp- since that time is better spent improving other aspects of the apps ecosystem at this stage. Multiple subdomains is not too hard to create for the average developer, now that we have integration with github.
Btw, I'm in agreement that this is quite important, just not needed for v1 (I'd argue for v1 things to focus heavily on stability, rather than features, given that we are currently in red for quality for Firefox OS against smoke tests). I've heard app management sites complain directly about this (e.g. Mobile Roadie). 

We should make this a topic for the apps work week btw and plan out what work needs to be done to allow for multiple webapps per origin and file bugs accordingly.
(In reply to Jason Smith [:jsmith] from comment #8)
> We should make this a topic for the apps work week btw and plan out what
> work needs to be done to allow for multiple webapps per origin and file bugs
> accordingly.

About installation, we could modify the installation directory name (and on Windows the registry key) to take into account not only the origin, but also the name of the application.
This way, we can allow multiple applications with different names from the same origin, and applications with the same name from different origins. Looks like a good trade-off.
(In reply to Marco Castelluccio from comment #9)

> About installation, we could modify the installation directory name (and on
> Windows the registry key) to take into account not only the origin, but also
> the name of the application.
> This way, we can allow multiple applications with different names from the
> same origin, and applications with the same name from different origins.
> Looks like a good trade-off.

There's no guarantee that apps name will be unique. Could you just use the manifest URI?
We could also simply use the app's localeId as a directory name. There is a bug to make it always incrementing so app will never have the same localeId. This is a basecamp blocker for security. See bug 775327.
(In reply to Mounir Lamouri (:mounir) (on VACATION until August 5th) from comment #11)
> We could also simply use the app's localeId as a directory name. There is a
> bug to make it always incrementing so app will never have the same localeId.
> This is a basecamp blocker for security. See bug 775327.

It is certainly possible to fix bug 775327 without supporting multiple apps per origin, right? While we should strive to support multiple apps per origin on desktop & android ASAP (B2G already supports it AFAIK), I think we can move to a more secure AppID generation mechanism without this.
(In reply to Anant Narayanan [:anant] from comment #12)
> (In reply to Mounir Lamouri (:mounir) (on VACATION until August 5th) from
> comment #11)
> > We could also simply use the app's localeId as a directory name. There is a
> > bug to make it always incrementing so app will never have the same localeId.
> > This is a basecamp blocker for security. See bug 775327.
> 
> It is certainly possible to fix bug 775327 without supporting multiple apps
> per origin, right? While we should strive to support multiple apps per
> origin on desktop & android ASAP (B2G already supports it AFAIK), I think we
> can move to a more secure AppID generation mechanism without this.

Sure. I was actually just suggesting that we could use localeId for the directory name.
Component: General → DOM: Apps
Product: Web Apps → Core
Given that we wouldn't hold the release for this I believe it's not blocking. That said, I definitely think we should fix the B2G code to allow this given that it requires relatively small code changes (if any)
blocking-basecamp: ? → -
Could we make the bug a soft-blocker then maybe?
(In reply to Mounir Lamouri (:mounir) (on VACATION until August 5th) from comment #15)
> Could we make the bug a soft-blocker then maybe?

Let's talk about this at the apps work week and figure out a schedule for figuring this out (the implementation here is more than just b2g, and I'd caution exposing something on b2g and risk causing regressions on other platforms such as desktop webrt, android webrt, and aitc desktop).

Important Note: It takes more than just landing the implementation here for b2g to make this successful, as we no apps on marketplace making use of multiple apps per origin right now (the mentality is established of the one app per origin right now).
Note : I will only be in MV Thursday and Friday for the work week. Fixing the DOM Registry implementation is not too hard, but it means that all webrt implementation must correctly set the mozapp attribute on apps frames.
(In reply to Fabrice Desré [:fabrice] from comment #17)
> Note : I will only be in MV Thursday and Friday for the work week. Fixing
> the DOM Registry implementation is not too hard, but it means that all webrt
> implementation must correctly set the mozapp attribute on apps frames.

Okay. Let me get bugs on file for each webrt and aitc desktop.

Also - Caitlin, can we get a session setup on Thursday for an implementation strategy for multiple apps per origin?
Blocks: 778277
Blocks: 778279
Blocks: 778286
Blocks: 778297
Work Session on the work week agenda for Thursday 11am
Fabrice, Jonas, Myk, Jason - please plan on attending. I'll find a vidyo room if I can.

Let's assume we can find a non-blocking solution that works cross-platform, if not, we know b2g get priority, right? 

( Also, a non-technical question: to a non-tech does this translate to multiple apps available at same url? (sorry) )
(In reply to Fabrice Desré [:fabrice] from comment #17)
> Note : I will only be in MV Thursday and Friday for the work week. Fixing
> the DOM Registry implementation is not too hard, but it means that all webrt
> implementation must correctly set the mozapp attribute on apps frames.

Why? Keep in mind that in WebRT we use a separate gecko profile for each app, so even if you have multiple apps from the same origin their data won't ever collide no matter what.
(In reply to Jonas Sicking (:sicking) from comment #20)

> Why? Keep in mind that in WebRT we use a separate gecko profile for each
> app, so even if you have multiple apps from the same origin their data won't
> ever collide no matter what.

Well, ok - let's say that to implement eg. getSelf(), we have to know which manifest url if any is tied to the current page.
(In reply to Caitlin Galimidi from comment #19)
> ( Also, a non-technical question: to a non-tech does this translate to
> multiple apps available at same url? (sorry) )

No. Currently, if you are example.com and want to have two apps, you have to do:
app1.example.com/manifest.webapp and app2.example.com/manifest.webapp, doing example.com/app1/mainefest.webapp and example.com/app2/manifest.webapp wouldn't be allowed.
This bug is about making any of the previous manifest URL allowed.
with multiple apps per domain, what's the behavior of when example.com calls getSelf()?
(In reply to :Felipe Gomes [offline 20-24, slow resp. 25-28] from comment #23)
> with multiple apps per domain, what's the behavior of when example.com calls
> getSelf()?

It should return the app that was launched and navigated to example.com - That's why we'll need some mechanism in webrt to support that (we already have it in b2g).
yeah but what about inside Firefox itself, not as a standalone app? If the user navigates to example.com and it calls getSelf()?

We can't have it working differently on firefox and webrt because we've been advocating that it would always work the same (so that developers can use the developer tools for example)

Note: I'm not trying to say we can't do this, I'm just trying to figure out a sensible behavior to be implemented.

Perhaps the definition of getSelf needs to be changed to be defined as returning an array instead of a single app object? Although this will probably break many apps if they are using getSelf. Some kind of magical object that works as an array and an app object (accessing the first element of the array)?
In WebRT getSelf() should only an App object, X, if all the following conditions are true:

* We are currently running in a WebRT instance for app X
* getSelf() is called in a page which has the same origin as app X
* getSelf() is called in a page which is same-origin with all frames in the frame
  parent chain all the way to the top-level frame.
Depends on: 779982
Depends on: 786303
No longer blocks: 778286
No longer blocks: 778297
Now being tracked in bug 778277.
No longer blocks: 778277, 778279
Status: NEW → RESOLVED
Closed: 11 years ago
No longer depends on: 786303, 779982
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.