Closed
Bug 775847
Opened 13 years ago
Closed 12 years ago
WebApps code should allow more than one webapp per origin
Categories
(Core Graveyard :: DOM: Apps, defect)
Core Graveyard
DOM: Apps
Tracking
(blocking-basecamp:-)
RESOLVED
DUPLICATE
of bug 778277
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).
Comment 1•13 years ago
|
||
CCing Anant since I think he said this may cause issues with receipt verification flows.
Reporter | ||
Comment 2•13 years ago
|
||
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: --- → ?
Updated•13 years ago
|
Component: General → DOM: Mozilla Extensions
Updated•13 years ago
|
Component: DOM: Mozilla Extensions → General
Product: Core → Web Apps
Version: Trunk → unspecified
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
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.
Comment 5•13 years ago
|
||
(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.
Comment 6•13 years ago
|
||
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
Comment 7•13 years ago
|
||
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.
Comment 8•13 years ago
|
||
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.
Comment 9•13 years ago
|
||
(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.
Comment 10•13 years ago
|
||
(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?
Reporter | ||
Comment 11•13 years ago
|
||
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.
Comment 12•13 years ago
|
||
(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.
Reporter | ||
Comment 13•13 years ago
|
||
(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.
Updated•13 years ago
|
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: ? → -
Reporter | ||
Comment 15•13 years ago
|
||
Could we make the bug a soft-blocker then maybe?
Comment 16•13 years ago
|
||
(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).
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
(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?
Comment 19•13 years ago
|
||
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.
Comment 21•13 years ago
|
||
(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.
Reporter | ||
Comment 22•13 years ago
|
||
(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.
Comment 23•13 years ago
|
||
with multiple apps per domain, what's the behavior of when example.com calls getSelf()?
Comment 24•13 years ago
|
||
(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).
Comment 25•13 years ago
|
||
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.
Comment 27•12 years ago
|
||
Now being tracked in bug 778277.
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•