Open Bug 1285858 Opened 3 years ago Updated Last year
Support manifest display: standalone display mode
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
In general multiple entries for the same activity can be achieved by defining documentLaunchMode in the manifest or using the FLAG_ACTIVITY_NEW_DOCUMENT 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 ( 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:  (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.  https://developer.android.com/reference/android/R.attr.html#documentLaunchMode  https://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_DOCUMENT  https://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK  https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)
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.
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+
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
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)?
No longer depends on: webmanifest
I removed webmanifest as a blocker since we have enough manifest functionality to have standalone mode working
Hello, I'll be taking this feature as QA.
QA Contact: oana.horvath
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.
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)
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!
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
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
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 :))
Taking meta bugs out of dependencies
No longer depends on: 1300570
Deassigning because people are working on this now that arent me
Assignee: dharvey → nobody
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(!).
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.