Add support of installing of multiple apps off of the same origin for the android web runtime

RESOLVED FIXED in Firefox 34

Status

()

Firefox for Android
Web Apps
P1
enhancement
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: jsmith, Assigned: myk)

Tracking

Trunk
Firefox 34
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox16 affected, firefox17 affected, fennec-)

Details

(Whiteboard: [WebRuntime][blocking-webrtandroid1-])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

6 years ago
In bug 775847, the proposal has been put out to add support for installing of multiple apps off of the same origin in the DOM registry for the mozapps API. This bug aims to provide the implementation to support installing of multiple apps off of the same origin in the android web runtime. Steps to figure this out include:

- Identifying any implementation areas that assume the one app per origin rule
- Identify any UI exposure that establishes a mentality for one app per origin that may need to be changed
- Implementing those said pieces needed to allow for multiple apps per origin
(Reporter)

Updated

6 years ago
Depends on: 775847
(Reporter)

Updated

6 years ago
Blocks: 778297
This needs a priority decision.
tracking-fennec: --- → ?
status-firefox16: --- → affected
status-firefox17: --- → affected
(Reporter)

Updated

6 years ago
Priority: -- → P1
(Reporter)

Comment 2

6 years ago
Based on today's apps discussion, I'd say this is really important to get done soon. As soon as we close out our blockers to be able to ship a v1 on android, I'd suggest we make this a top priority for v2 on Android (i.e. Firefox 17). I therefore suggest we make this tracking-fennec: 17+
tracking-fennec: ? → +
(Reporter)

Updated

6 years ago
Duplicate of this bug: 785456
(Reporter)

Updated

6 years ago
Duplicate of this bug: 785439
(Reporter)

Updated

6 years ago
Whiteboard: [blocking-webrtandroid1-]
(Reporter)

Comment 5

6 years ago
Sending this back into triage - we aren't doing some forseeable future. I don't think we need to track this anymore until the priority for this becomes evident.
tracking-fennec: + → ?
Priority: P1 → --
tracking-fennec: ? → -
(Reporter)

Comment 6

5 years ago
We aren't implementing this anytime soon.

==> P3
Priority: -- → P3
(Reporter)

Updated

5 years ago
No longer blocks: 778297
(Reporter)

Updated

5 years ago
No longer depends on: 775847
(Reporter)

Updated

5 years ago
Depends on: 778277
(Reporter)

Updated

5 years ago
Blocks: 778277
No longer depends on: 778277
(Assignee)

Updated

5 years ago
Severity: normal → enhancement
(Assignee)

Updated

4 years ago
Whiteboard: [blocking-webrtandroid1-] → [WebRuntime][blocking-webrtandroid1-]
(Assignee)

Comment 7

4 years ago
Taking and reprioritizing, as Fabrice would like to land DOM support for multiple apps per origin early in the next cycle.
Assignee: nobody → myk
Status: NEW → ASSIGNED
Priority: P3 → P1
(Assignee)

Comment 8

4 years ago
Created attachment 8456250 [details] [diff] [review]
work in progress that updates about:apps

This WIP updates about:apps to identify apps by manifest URL instead of origin.
(Assignee)

Comment 9

4 years ago
Created attachment 8456942 [details] [diff] [review]
wip2: launch apps by package name
Attachment #8456250 - Attachment is obsolete: true
(Assignee)

Comment 10

4 years ago
Created attachment 8458755 [details] [diff] [review]
wip3: also remove obsolete origin-based homescreen shortcut creation

This also removes the obsolete origin-based homescreen shortcut creation code.  I think this is a complete set of fixes, but I need to do more testing to confirm, and there's some code in this patch that I added but ended up not using, so I'll need to remove that stuff.
Attachment #8456942 - Attachment is obsolete: true
(Assignee)

Comment 11

4 years ago
Created attachment 8459803 [details] [diff] [review]
patch v1: identify apps by manifest URL and APK package name

Ok, tested and cleaned up.  There are a few fixes here:

1. about:apps was identifying apps by origin, so it would mistake two apps from the same one.  Now it identifies them by manifest URL.

2. EventListener was calling GeckoAppShell.getWebappIntent, which identifies apps by origin, in order to launch them.  Now it creates the intent using PackageManager.getLaunchIntentForPackage, since the new implementation stores the APK package name, so we don't need to craft a custom intent.

3. GeckoAppShell.createShortcut was also calling GeckoAppShell.getWebappIntent to create "webapp" shortcuts, but nothing creates such shortcuts anymore, since we removed that feature from about:apps.  So I removed support for the "webapp" shortcut type.

And since that's the only shortcut type that GeckoAppShell treats differently, I further removed support for shortcut types generally, which simplifies createShortcut and related methods significantly.

(But I left in the aIntent parameter to nsIShellService.createShortcut, in case there are addons or other code outside Central that is using that interface.  But we could remove that too, if it's strictly an internal interface.)

4. GeckoAppShell.removeShortcut was also calling GeckoAppShell.getWebappIntent, but it's no longer being called from anywhere.  So I removed it, which enabled me to remove getWebappIntent itself.

Note that WebappImpl uses the origin for a couple different purposes, but it never uses it to identify apps uniquely, so those uses don't need to change.
Attachment #8458755 - Attachment is obsolete: true
Attachment #8459803 - Flags: review?(mark.finkle)
Comment on attachment 8459803 [details] [diff] [review]
patch v1: identify apps by manifest URL and APK package name

You can probably remove these constants too:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoAppShell.java#138
Attachment #8459803 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 13

4 years ago
(In reply to Mark Finkle (:mfinkle) from comment #12)
> You can probably remove these constants too:
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/
> GeckoAppShell.java#138

Good point!  I removed them in the version I pushed to fx-team:

https://hg.mozilla.org/integration/fx-team/rev/5796b420f292
https://hg.mozilla.org/mozilla-central/rev/5796b420f292
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
You need to log in before you can comment on or make changes to this bug.