1285858 - Support manifest display: standalone display mode

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P5)

Description

[709922234]

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

Comment 1

[Marcos Caceres [:marcosc]]

Related: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1104916

Comment 2

[Dale Harvey (:daleharvey)]

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?

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

(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..)

Comment 4

[Dale Harvey (:daleharvey)]

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

Comment 5

[Dale Harvey (:daleharvey)]

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.

Comment 6

[Sebastian Kaspari (:sebastian; :pocmo)]

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)

Comment 7

[Dale Harvey (:daleharvey)]

Attachment: 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.

Comment 8

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Thanks Dale! we'll talk about this next week

Comment 9

[Salvador de la Puente González [:salva]]

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!

Comment 10

[Salvador de la Puente González [:salva]]

> 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 11

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

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

Comment 12

[Sebastian Kaspari (:sebastian; :pocmo)]

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.

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 14

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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)?

Comment 15

[Dale Harvey (:daleharvey)]

I removed webmanifest as a blocker since we have enough manifest functionality to have standalone mode working

Comment 16

[Oana Horvath [:ohorvath]]

Hello, I'll be taking this feature as QA.

Comment 17

[Oana Horvath [:ohorvath]]

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.

Comment 18

[Dale Harvey (:daleharvey)]

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)

Comment 19

[Oana Horvath [:ohorvath]]

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!

Comment 20

[Dale Harvey (:daleharvey)]

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

Comment 21

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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

Comment 22

[Dale Harvey (:daleharvey)]

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 :))

Comment 24

[Dale Harvey (:daleharvey)]

Taking meta bugs out of dependencies

Comment 25

[Dale Harvey (:daleharvey)]

Deassigning because people are working on this now that arent me

Comment 26

[Stephen Eisenhauer (BHSPitMonkey)]

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(!).

Comment 27

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 28

[fuglede]

Curious to see that the test app indeed hides the address bar; I came across this bug because I have an example of a PWA in which setting "display" to "standalone" does not suffice to hide the address bar in Android Firefox (even if it works as expected in Android Chrome); https://stackoverflow.com/q/60803901/5085211

Comment 29

[jaromanda]

display standalone manifest setting was working fine for me until the latest (version 79.x) update to Android Firefox - i.e

window.matchMedia("(display-mode: standalone)").matches

was true in 68.x, but in 79.x it is false, and

window.matchMedia("(display-mode: browser)").matches

is now true. Consequently, any styling in the form

@media all and (display-mode: standalone) {
}

Is no longer applied.

Comment 30

[cleriotsimon]

I can reproduce the issue @jaromanda is facing, display mode is set to browser in the PWA instead of standalone even in the latest Firefox Android version (80.1.3)

Comment 31

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.