Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Home screen installation is available in Firefox Android and UC browser #36

Open
kenchris opened this issue Dec 20, 2017 · 15 comments
Open

Comments

@kenchris
Copy link

Home screen installation is available in Firefox Android and UC browser

@NOtherDev
Copy link
Owner

Well I don't know how to handle this one correctly yet.

First is that technically speaking, all browsers have the "create link" feature available somewhere deep in the menu (incl. Safari). So maybe I should put a green tick everywhere. But maybe I should distinguish the "proper" support, that somehow advertizes/prompts the user if the site has a proper manifest. Chrome-like prompts are one option, but Samsung Internet has another kind of icon for manifest-enabled pages - that should probably be sufficient. Or maybe "proper" is only the approach with WebAPK that lets the app get rid of the "shortcut" badge and makes the PWA a first-class citizen? I'm not sure.

The other thing is that it's hard to detect the level of support without browser sniffing that I don't want to do. Right now the tick is based on beforeinstallprompt event existence and this is obviously biased toward Chrome-like prompting behavior and accidentally (due to Chromium inheritance) also marks Samsung Internet with the tick.

@kenchris
Copy link
Author

@marcoscaceres @anssik

@kenchris
Copy link
Author

@kenchris
Copy link
Author

@kenchris
Copy link
Author

@NOtherDev
Copy link
Owner

NOtherDev commented Dec 21, 2017

I gave it a bit more thought and ideally I think I should detect a support for display-mode: standalone, but again, I don't know how to feature-detect it.

I can detect if the browser understands this media query at all, but it's far from being ideal. Safari will be ❌ but all the desktop browsers (including Safari Technology Preview) will be ✔️ - and this is incorrect if we want to answer the question "does this browser is able to create a thing on my home screen".

What I should be detecting is whether the browser is able to actually use display-mode: standalone in any way (not if it is in standalone at the moment obviously, but if there is a different behavior for standalone implemented at all). But nothing came to my mind yet.

@tomayac
Copy link

tomayac commented Dec 21, 2017

Maybe use @supports (https://developer.mozilla.org/en-US/docs/Web/CSS/%40supports) to feature-detect display-mode (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode) support and then apply a style to a throw-away element if currently the display mode is not standalone (meaning we’re just a regular tab) that you can then check with getComputedStyle().

@supports (display-mode: standalone) {
  .throw-away {
    color: rebeccapurple;
  }
}

…and then…

if (window.getComputedStyle(document.querySelector('.throw-away')).color === 'rebeccapurple') {
  // A2HS supported
}

Not sure if the @supports check would work like that. On mobile now, so writing this freestyle without actually testing.

@NOtherDev
Copy link
Owner

Thanks @tomayac. I explored this route too, but from what I can see it is only able to determine if the browser IS in standalone mode. What I want to determine is if the browser IS ABLE TO actually enter this mode.

What I did was:

let style = document.createElement('style')
document.getElementsByTagName('body')[0].appendChild(style)
style.innerText = '@media (display-mode: standalone) {}}'
let result = document.styleSheets[document.styleSheets.length - 1].cssRules[0].media.mediaText

If the result is not equal to (display-mode: standalone) then the browser was unable to understand my stylesheet.

But, for instance, it will still succeed in Chrome on desktop, where we have no meaningful A2HS available.

@tomayac
Copy link

tomayac commented Dec 22, 2017

Well, technically, there is the concept of chrome://apps, so you could argue. But I don’t have a better check neither.

@tomayac
Copy link

tomayac commented Jan 15, 2018

Check if the browser understands Web App Manifests as the universally agreed-on requirement for add to home screen:

document.createElement('link').relList.supports('manifest')

tomayac added a commit to tomayac/pwa-feature-detector that referenced this issue Jan 15, 2018
@kenchris
Copy link
Author

Nice one @tomayac !

@NOtherDev
Copy link
Owner

Yes, this is neat. Although I still have some doubts what a "support for add to home screen" means.

Excerpts from the Web App Manifest spec

On the one hand we have:

An installation process is an attempt by the user agent to install a web application. The details of such a process (i.e., the display of an install UI, and any resulting IO operations of the host OS) are left up to implementers. Implementers need to be aware that there are privacy and security considerations that directly relate to the installation process.

For the purpose of this specification, the installation succeeded once the installation process succeeds in installing the web application (e.g., an icon was successfully placed onto the device's homescreen).

Reading this it seems like any way of putting a link/shortcut on the home screen qualifies as an installation. UC fulfils this for sure, Samsung Internet, too.

Although we can also read that:

A common use case of a manifest is for a user agent to install a web application; whereby the user agent provides the end-user with a means of instantiating a new top-level browsing context that has the manifest's members applied to it. That is, the manifest's members, or their defaults, are in effect on the top-level browsing context. This distinguishes an installed web application from a traditional bookmark, as opening a web page from a traditional bookmark will not have the manifest's properties applied to it.

UC Browser does not apply any manifest-defined theming when I open the link from the home screen. It does not use start_url. It does not even use the icon specified in the manifest (or I'm doing something wrong). It is just a bookmark, it seems.

In the installation algorithm we can also read that:

If the installation succeeded, queue a task on the application life-cycle task source to fire an event named appinstalled at the window object.

So we might check for 'onappinstalled' in window as a sign of manifest-spec conformity. And it is false on both UC Browser and Samsung Internet.

@tomayac
Copy link

tomayac commented Feb 6, 2018

FWIW, I settled with this solution for PWA Feature Detector:

document.createElement('link').relList.supports('manifest') &&
    'onbeforeinstallprompt' in window

This makes sure the browser understands what a Web App Manifest is, and has at least the theoretical ability to trigger a prompt. The event is well-documented and in the spec. One could go one step further and even check for onappinstalled, but I don't think this would add much value.

@NOtherDev
Copy link
Owner

NOtherDev commented Feb 6, 2018

@tomayac So you've ended up with the solution that rejects both Firefox Android and UC Browser, the ones you've started the discussion with?

I've opened your detector with Firefox Android and it proposed me to add to home screen even though you are displaying red cross there. So you're now aligned with What Web Can Do Today 😉. And we're both wrong in a sense.

@tomayac
Copy link

tomayac commented Feb 6, 2018

I guess you’re right in your observation, yes. I feel like right now there’s just no one right or wrong approach, more an approximation of what one personally considers a valid “add to home screen”. The spec also (on purpose it seems) is pretty vague as to the when and how a prompt should trigger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants