Devtools: "Add to Home screen" button does not communicate the successful intent resolution |
||||||||
Issue descriptionThe "Add to homescreen" string in devtools is a bit of a misnomer since we don't have the concept of adding to home screen on desktop. Additionally, when the desktop PWAs feature (chrome://flags/#enable-desktop-pwas) or experimental app banners features (chrome://flags/#enable-experimental-app-banners) are active, it appears as though this button does nothing. What is actually happening is that the add to home screen API has changed and now requires a user gesture on a JavaScript event to actually trigger the dialog. These features are already launched on Android and Chrome OS, and are launching on Windows/Linux (M70) and Mac (M72) in the near future. We should rename the string here to be "Trigger beforeinstallprompt", which is what it actually does now (and what our public docs say to catch in order to trigger the prompt). See https://developers.google.com/web/updates/2018/06/a2hs-updates.
,
Oct 8
,
Oct 10
Proposed string rejected. Marking as available.
,
Oct 10
Does this only apply to the Desktop PWA? The button there is intended to be used in the context of the mobile emulation primarily. Desktop PWA is a new to the game, so I'm mostly interested in delivering emulated mobile experience there.
,
Oct 10
It applies equally to mobile and desktop. CrOS since M67, Android since M68, Win/Linux from M71, Mac from M72/M73 (depending on when it launches). More developers are going to be using this in a desktop context given the big push for desktop PWAs that will be coming.
,
Oct 10
,
Oct 10
In my opinion the string never made sense for mobile either. It can't add to the homescreen on a desktop. Coming up with a better string would be good.
,
Oct 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/158827d3b5f8da52061fbba9267c9f86b69e491b commit 158827d3b5f8da52061fbba9267c9f86b69e491b Author: Pavel Feldman <pfeldman@chromium.org> Date: Thu Oct 11 02:41:12 2018 Revert "Replace "Add to homescreen" string with "Trigger beforeinstallprompt" in devtools." This reverts commit e3f03230114df31404f3cb152df15735eae2dc26. Reason for revert: the old label was more user-friendly. The new one is technically correct, but is not user readable. Original change's description: > Replace "Add to homescreen" string with "Trigger beforeinstallprompt" in devtools. > > This new string is more semantically accurate, since there is no home > screen concept on desktop platforms. Additionally, it is more behaviourally > accurate, since add to home screen behaviour has changed from always > triggering an app banner to requiring a user gesture on a JavaScript API > call on the beforeinstallprompt event to trigger. > > BUG=891589 > > Change-Id: Ic24ea5170ca384b8858bc89d3e1efd22d69de56c > Reviewed-on: https://chromium-review.googlesource.com/c/1257466 > Commit-Queue: Dominick Ng <dominickn@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#597393} TBR=dgozman@chromium.org,pfeldman@chromium.org,dominickn@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 891589 Change-Id: I51c39f075e08fef48186439928b63b77bdcf1991 Reviewed-on: https://chromium-review.googlesource.com/c/1274596 Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Pavel Feldman <pfeldman@chromium.org> Cr-Commit-Position: refs/heads/master@{#598642} [modify] https://crrev.com/158827d3b5f8da52061fbba9267c9f86b69e491b/third_party/blink/renderer/devtools/front_end/inspector_main/module.json [modify] https://crrev.com/158827d3b5f8da52061fbba9267c9f86b69e491b/third_party/blink/renderer/devtools/front_end/resources/AppManifestView.js
,
Oct 12
Pavel - do you have either a suggestion for a better string, or a someone that we can work with to get a suggestion? The current string has never been good. I think Dom's suggestion was better but also not ideal.
,
Oct 12
I think there is a misunderstanding of what this button does and why it was added. It had very little to do with the beforeinstallprompt event: - Users were not seeing the "Add to home" on their web apps in their phones. - There was zero insight into why that was happening - We needed to run the entire pipeline to validate manifest, deliver the event to the page and present all the associated errors to the user in console. - Users were not aware of the event or did not have to be aware of it - 'Add to home screen' was the shortest way to point them to the functionality they needed. - Pressing this button in 71 does validate the manifest, triggers the event and result in the app being added to the shelf. This is good enough for a mobile web app author to check everything. My understanding is that every statement above still stands, all the way up to M71. There is very little sense in triggering the event - users can call the handler in the console and mock the event to check their functionality. This feature is not about the handler.
,
Oct 12
>- Pressing this button in 71 does validate the manifest, triggers the event and result in the app being added to the shelf. This is good enough for a mobile web app author to check everything. What OS are you using? On Chrome OS (M67+), Android (M68+), Windows (M71+), Linux, and (M71+), this does nothing. The only OS where it will trigger a banner is Mac, and that will change in M72. You can even see the non-behaviour right now if you enable chrome://flags/#enable-desktop-pwas and try the button then. I tried to explain this offline - developers mocking the event will not help test this. A mocked event will not have the connection to the browser process required to trigger adding to shelf. Again, it will just do nothing. In the updated add to home screen flow, the only thing this feature can be about is triggering the handler, because there will no longer be an automatic add to home screen prompt. Desktop (Chrome OS, Win, Linux) already has this from M71, and we're planning on removing the mini-infobar currently shown occasionally on mobile.
,
Oct 12
> What OS are you using? I'm using MacOS, but I'm only interested in emulating the mobile behavior. I.e. the button should be fixed in M72 to deliver to the expectations on all the platforms. I'm not interested in desktop here at all, the only reason I want to see it added to shelf is to show that the intent has succeeded. > I tried to explain this offline - developers mocking the event will not help test this. A mocked event will not have the connection to the browser process required to trigger adding to shelf. We are not trying to trigger the shelf, we are trying to validate the manifest. The only reason why triggering the shelf is useful above is for the user to understand that the intent succeeded. It might be that the desktop PWA contribute to the confusion here, but desktop PWA is not a priority for this use case. We should reformulate the issue description and make appropriate fix to the functionality, not the issue.
,
Oct 12
fix to the functionality, not the *title
,
Oct 12
If the only thing we're interested in is validating the manifest, that is covered by the "Progressive web app" audit in the Lighthouse tab in devtools. That being said, I think there is still significant value in allowing developers to manually trigger beforeinstallpromptevent via this link - they can use it to rigorously test their install UX (button shows up correctly, works when pressed, disappears when appinstalledevent is fired). None of that is covered by the PWA Lighthouse audit. We constantly get requests for repeatable, reliable testing, and that is what this link provides. It's just mislabeled right now. Also, I still don't understand the lack of interest in desktop. We are going to see more desktop developers trying to utilise the install functionality, and have an org-wide commitment to desktop PWAs. Improving the developer experience of working on desktop PWAs through devtools will support this.
,
Oct 12
,
Oct 12
@Pavel Feldman: As we are not very sure about the test steps to proceed further, could you please help us by providing the required info to test and verify this issue(....if this can be verified manually). Note: Tried checking in DevTools for "Add to Home screen" button, but couldn't find any. It would also be highly helpful if mentioned about any pre-condition to test this(...if any). Thanks! |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by bugdroid1@chromium.org
, Oct 6