Support manifest display: standalone display mode

NEW
Unassigned

Status

()

Firefox for Android
Web Apps
a year ago
20 days ago

People

(Reporter: 709922234, Unassigned)

Tracking

(Depends on: 4 bugs, Blocks: 1 bug, {dev-doc-needed})

48 Branch
dev-doc-needed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ptototype][fennec 54])

Attachments

(1 attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160606114208




Expected results:

Does not display the toolbar
Choose from the system app switcher
Blocks: 1212648
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 997779
Related: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1104916
Keywords: dev-doc-needed
Starting to investigate this.

Snorp, I heard your team has started working on splitting the singleton assumption so that we may be able to run isolated instance of apps, is there any where I can track this?
Assignee: nobody → dale
(In reply to Dale Harvey (:daleharvey) from comment #2)
> Starting to investigate this.
> 
> Snorp, I heard your team has started working on splitting the singleton
> assumption so that we may be able to run isolated instance of apps, is there
> any where I can track this?

Have a look at LauncherActivity and CustomTabsActivity. That's the first step into having multiple activities with gecko views (Work in progress..)
Thanks Sebastian

So I had thought I had written my initial thoughts and notes down here, but apparently not, so here goes

1. Navigating away from a PWA

So a user has installed a nice web app, say https://platform-status.mozilla.org/, they launch it, it opens in its own window, has its own entry in the android task switcher. However on that web app there is a link to github.com in the footer, when they click on that link they have exited the app, they may want to know what this new origin is, the new website may not have a mobile friendly UI

(Chrome shows a mini url bar, Opera opens the url in the browser)

2. While browsing a PWA

The user may want to see / share the url, they may want to search the text within the page or access otherwise readily available browser tools. How do we let them do this?

(Currently Chrome has no way but has one planned, Opera has an experimental 'pull to open pwa url in browser')

3. Navigating to a PWA

The user has installed https://platform-status.mozilla.org/, when they get a link that goes there, do they get a standalone app experience or do they open it in a normal browser tab?


(I dont believe anyone supports this yet)

These are all interrelated issues, for Firefox OS we were able to solve this by integrating the URL into the status bar but always accessible even in standalone mode, when a user navigated out of an app the url bar expanded by default, when they navigated to an app the url collapsed by default (but still accessible)

It would be amazing if we could do similiar with android however integration with the android task switcher may make that that complicated / impossible / totally easy
Sebastian you may be the best to answer this? (if not if you could forward it on it would be great). 

So the situation is a user has installed a web app, pokedex.org (but not opened it), they have opened a browser instance, are navigating the web and click on pokedex.org/pikachu

Ideally I believe we would like the url bar / browser chrome to dissapear, and a new 'pokedex' entry in the Android task switcher (preferably without opening app animations etc)

Similiarly the next situation would be the user navigates from pokedex.org/pikachu to github.com, the 'pokedex' task switcher entry dissapears, if there isnt already one an Firefox is started, and the browser chrome is shown.

Basically is there any way to control the Android task switcher? Without being overly familiar with Android I cant seem to find much to indicate this would be possible.
Flags: needinfo?(s.kaspari)
In general multiple entries for the same activity can be achieved by defining documentLaunchMode[1] in the manifest or using the FLAG_ACTIVITY_NEW_DOCUMENT[2] flag when launching an intent. This is a new in API level 21 (Android 5.0) though. Without that I think we will have to use separate activities and use the right task flags ([3] and others) to create separate tasks for them (What you see in the recent apps screen are actually tasks, which contain of a stack of activities; and nowadays "documents"). In general separate activities is not a bad idea - that's what we are doing for custom tabs too. Our regular BrowserApp (activity) is defined to be "singleTask" in the manifest for a couple of technical reasons.

In any case I guess you will need to intercept URL loads and decide whether to just open it or launch an Intent. I'm not sure how this is done on Gecko side. That's what a regular Android WebView offers: [4]

(In reply to Dale Harvey (:daleharvey) from comment #4)
> 1. Navigating away from a PWA
> [..]
> (Chrome shows a mini url bar, Opera opens the url in the browser)

Both should be possible with the approach to use separate activities. The mini URL bar is definitely easier. See comment below too.

(In reply to Dale Harvey (:daleharvey) from comment #4)
> 2. While browsing a PWA
>
> The user may want to see / share the url, they may want to search the text
> within the page or access otherwise readily available browser tools. How do
> we let them do this?

Maybe antlam can come up with a fancy solution. If we are working with separate activities then we could either somehow reveal a minimized UI or redirect the user to the actual browser activity (and hand-off the tab).

> 3. Navigating to a PWA
> 
> The user has installed https://platform-status.mozilla.org/, when they get a
> link that goes there, do they get a standalone app experience or do they
> open it in a normal browser tab?

Maybe we should treat the PWA like a native application and only show some indicator in the URL bar? For native apps we avoid popping the user out of the browser.

> These are all interrelated issues, for Firefox OS we were able to solve this
> by integrating the URL into the status bar but always accessible even in
> standalone mode, when a user navigated out of an app the url bar expanded by
> default, when they navigated to an app the url collapsed by default (but
> still accessible)

This is interesting. Unfortunately I do not have a Firefox OS device anymore to try this. I can only see us achieving something like this by only using our single task BrowserApp and using the document flags; but this is Android 21+.


Note that you are several steps ahead here: Currently Fennec does not fetch, parse or store the web app manifest. We will need to build a foundation to make the manifest available to fennec (on disk) and use this data for creating and launching home screen shortcuts. Nevertheless I think it makes sense to explore this here; just be aware that if you solve this then there are still components missing to actually use this in Fennec.

Just flag me again if you want to know more.

[1] https://developer.android.com/reference/android/R.attr.html#documentLaunchMode
[2] https://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_DOCUMENT
[3] https://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK
[4] https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)
Flags: needinfo?(s.kaspari)
Created attachment 8815744 [details]
Initial design doc for a standalone mode

So while I have been working on other things things this has been brewing around my head and wanted to get it down to describe what I think is the best plan (and apologies, not a visual designer so my 'mockups' are basic). 

The is far far simpler than what I talked about before and I think covers use case well, in terms of UX there is 2 main points

1. A gesture in which we can show chrome when we are in standalone mode, we may also want the opposite gesture to hide persistently hide chrome

2. A toolbar which does not have the tabs button

In terms of code the main consideration is The ability to determine given a url whether it falls within the scope of a previously installed web app

This is all a fairly large chunk of work that I will split up into dependency bugs that hopefully I will be able to land behind a pref

Would be extremely happy to hear any feedback about this, whether about use cases it is missing, technical limitations / approaches, or UX features that may be improved.
Attachment #8815744 - Flags: feedback?(s.kaspari)
Attachment #8815744 - Flags: feedback?(jcheng)
Attachment #8815744 - Flags: feedback?(alam)
Depends on: 1321320
Thanks Dale! we'll talk about this next week
Comment on attachment 8815744 [details]
Initial design doc for a standalone mode

I'm wondering if we could use an extra icon to short cut "Add to home screen" or if this is a good idea at all. +1 to reuse the "Add to home screen" item but promoting it to a be a first level entry.

I agree with you on the gesture for displaying / hiding chrome must be carefully designed. See my comments in the bug.

Nice work, Dale!
> 1. A gesture in which we can show chrome when we are in standalone mode, we may also want the
> opposite gesture to hide persistently hide chrome
>
> 2. A toolbar which does not have the tabs button

We should be careful with this since browser gestures can conflict with in-site gestures. Nevertheless, the standard says that standalone mode accepts some UI elements like a status bar. Perhaps we could add a minimum UI in the form of a browser zone at the bottom. In this zone, we could use an edge gesture (since this gesture is not initiated in the content window) to display more browser Chrome.
Comment on attachment 8815744 [details]
Initial design doc for a standalone mode

Thanks Dale!

This is interesting. And something we'll consider as a part of our "Add to homescreen" scope for PWA-related UX things
Attachment #8815744 - Flags: feedback?(alam) → feedback-
Comment on attachment 8815744 [details]
Initial design doc for a standalone mode

This should be a google doc so that I can comment inline. :)

This looks good to me in general. I have some small concerns around switching between browser and PWAs: I guess technically they will be separate activities and the transition might not be as smooth as described in the doc (e.g. "the chrome will reappear"). I think to fully understand the interaction between browser and PWAs we should also look at the "recent apps" screen and whether they will be completely separate entries (I think they should) -> This also means just having the chrome appear/disappear is not sufficient if they are actually separate things from Android's point of view.

Another technical concern is switching between both worlds while browsing: Intercepting every page load and letting it bubble up to Java to decide whether this is a PWA or not could affect the performance negatively. This is just a guess and we probably can avoid calling Java code completely for this.
Attachment #8815744 - Flags: feedback?(s.kaspari) → feedback+
See Also: → bug 1126479

Updated

11 months ago
Depends on: 1336355
Comment on attachment 8815744 [details]
Initial design doc for a standalone mode

Hi Dale, thanks for the UX proposal. I will clear the feedback flag and have the UX team to comment on the UX for PWA once the UX exploration is done. As we discussed last week, let's not get blocked by the UX work and continue moving forward on the platform pieces that's independent of UX. Thanks
Attachment #8815744 - Flags: feedback?(jcheng)
Whiteboard: [ptototype][fennec 54]

Updated

10 months ago
Depends on: 1337341

Updated

10 months ago
Depends on: 1234558
Hi Dale,

Looks like bug 1336355 and bug 1337341 are the last two pieces for the stand-alone mode prototype.
Are we still expecting to have both land before March6 (54 branch)?
Depends on: 1347154
Depends on: 1347165
Depends on: 1347605
No longer depends on: 997779
I removed webmanifest as a blocker since we have enough manifest functionality to have standalone mode working
Depends on: 1347611
Depends on: 1347616
Depends on: 1300570

Comment 16

9 months ago
Hello, I'll be taking this feature as QA.
QA Contact: oana.horvath
Depends on: 1348794

Comment 17

9 months ago
I've started my work on this feature and made a Test plan which I'll be updating as I continue my progress. You can check the wiki page here: https://wiki.mozilla.org/QA/Fennec/Support_manifest_display-standalone_display_mode.
Depends on: 1350236
Depends on: 1346542
Depends on: 1351554
Depends on: 1351555
Depends on: 1351556

Updated

9 months ago
Depends on: 1348686, 1351739

Updated

9 months ago
Depends on: 1351834
Depends on: 1352004

Updated

9 months ago
Depends on: 1352099

Updated

9 months ago
Depends on: 1347585

Updated

9 months ago
Depends on: 1352378
Depends on: 1352394
Depends on: 1352433
Hey Oana

So I have been spending some thinking about / discussing testing, most of this is thanks to Sebastian :)

I have made a test application @ https://daleharvey.github.io/testapp/ (source: https://github.com/daleharvey/testapp) that makes testing some of the cases easier. This can be edited at any time so if there is any requests for use cases to add then please say

Ideally we should test with an addon enabled that depends on the url bar, not hugely familiar with android addon system yet so will try to look for something relevant

We should be testing with "Dont keep activities" (in developer settings) enabled, as that makes it easier to hit edge cases where android has killed background apps

and lastly we should test in guest mode (I did not realise that existed)
Depends on: 1352726

Updated

9 months ago
Depends on: 1351169

Updated

9 months ago
Depends on: 1352991

Updated

8 months ago
Depends on: 1353714

Comment 19

8 months ago
Thank you for the test app, it'll be pretty handy! I'd add some fields for permissions testing: audio, video/camera, storage access, and pop-ups when you have some time, but I can also find these in other apps otherwise. 
Also, I've made a few notes in my test cases doc. They are written in red. Could you review them and maybe clarify a few things for me? 
Thanks!

Updated

8 months ago
Depends on: 1353857

Updated

8 months ago
Depends on: 1353868
Depends on: 1162150
Depends on: 1325021
Wesley (or anyone else). I was wondering what the android release schedule looks like, it was mentioned that April 20th is branch day and everything should be complete by then. The bulk of this work is complete and its looking like "around" branch day all P1's should be finished with some possible stragglers, However it has not had a large amount of testing and I would be surprised if there were no more crashing bugs.

Does the 20th branch mean a new release is cut and this is shipped to users who will not receive bug fixes until the next major in X weeks/months. Or does it mean we should be feature complete and entering Aurora / Beta where we have a chance to stabilize?

Cheers
Dale
Flags: needinfo?(whuang)
Thank you for bring this up.
As the Project Dawn (or the end of Aurora) is happening, current 55 will not branch to aurora but instead goes to beta directly at June13. More info is available on the mailing list mobile-firefox-dev.
Between now and then is the period we can stabilize. 
We should treat the current nightly a little differently than we did before since there's no aurora channel for the 55.
That said, we will still target the April/20th feature complete although there won't be branching stuff at that time.
We will stabilize on nightly and polish it to beta/release.

(In reply to Dale Harvey (:daleharvey) from comment #20)
> Wesley (or anyone else). I was wondering what the android release schedule
> looks like, it was mentioned that April 20th is branch day and everything
> should be complete by then. The bulk of this work is complete and its
> looking like "around" branch day all P1's should be finished with some
> possible stragglers, However it has not had a large amount of testing and I
> would be surprised if there were no more crashing bugs.
> 
> Does the 20th branch mean a new release is cut and this is shipped to users
> who will not receive bug fixes until the next major in X weeks/months. Or
> does it mean we should be feature complete and entering Aurora / Beta where
> we have a chance to stabilize?
> 
> Cheers
> Dale
Flags: needinfo?(whuang)
Great thanks Wesley

I am on PTO now until the 18th, I will deassign myself from all bugs just to make sure that there is no confusion that I am actively working on them but will jump straight back on on the 18th (if they arent already cleared :))

Updated

8 months ago
Depends on: 1351808

Updated

8 months ago
Depends on: 1355094

Updated

8 months ago
Depends on: 1355098

Updated

8 months ago
Depends on: 1355513
Depends on: 1355676

Updated

8 months ago
Depends on: 1355824

Updated

8 months ago
Depends on: 1355847

Updated

8 months ago
Depends on: 1355852

Updated

8 months ago
No longer depends on: 1348794, 1350236, 1352378

Updated

8 months ago
Depends on: 1357438

Updated

8 months ago
Depends on: 1357443

Updated

8 months ago
Depends on: 1357779
No longer depends on: 1162150
No longer depends on: 1353868
Duplicate of this bug: 1360213

Updated

8 months ago
Depends on: 1360455
Taking meta bugs out of dependencies
No longer depends on: 1300570

Updated

7 months ago
No longer depends on: 1357779
Component: General → Web Apps
No longer depends on: 1347165
No longer depends on: 1348686
No longer depends on: 1355098

Updated

7 months ago
Depends on: 1363049

Updated

7 months ago
Depends on: 1363052
Depends on: 1363359

Updated

7 months ago
Depends on: 1364044

Updated

7 months ago
Depends on: 1364052

Updated

7 months ago
Depends on: 1368024

Updated

6 months ago
Depends on: 1365868

Updated

6 months ago
Depends on: 1377320

Updated

6 months ago
Depends on: 1367077
(Reporter)

Updated

5 months ago
Depends on: 1379405
Depends on: 1386154

Updated

4 months ago
Depends on: 1388747

Updated

4 months ago
Depends on: 1388750

Updated

4 months ago
Depends on: 1388755

Updated

4 months ago
Depends on: 1388757

Updated

4 months ago
Depends on: 1388760

Updated

4 months ago
Depends on: 1388763
Deassigning because people are working on this now that arent me
Assignee: dharvey → nobody
Depends on: 1394766
Depends on: 1364471

Updated

3 months ago
Depends on: 1398065

Updated

3 months ago
Depends on: 1398067
Some observations in Nightly (on Android 7.1):

- The icon added to my home screen by Firefox is much larger (has less padding) than the same site's icon as added from Chrome.
- When the icon is added via Chrome, a shell APK is generated and registered with the Android package manager. Because of this, a long-press on the home screen icon allows me to tap Uninstall, which will prompt me to remove that web app's icon and data. When added via Firefox, the long-press/Uninstall action on the icon results in requesting an uninstall of Firefox itself(!).
See Also: → bug 1420065
You need to log in before you can comment on or make changes to this bug.