Bugzilla

RE "accidentally rejected" -- let me add one more more-realistic user-story here: in my real-world use-case, I didn't really "accidentally reject" the dialog.

Really, I saw the prompt, felt temporarily suspicious/paranoid, wanted to do some quick research before granting, and also wanted to see if I could still get where I needed after clicking cancel [e.g. if the web page provided some useful fallback instructions that didn't require this dialog].  Unfortunately, this particular website's failure-mode is **not** graceful; it doesn't even load a website.  It just checks your UA and (on Android devices) redirects to the URL `market://details?id=com.zvworkplace.member`

In reply to Roger Yang [:royang] from comment #5)
> There are two solutions if you accidentally rejected open links in apps.
> 1. Use the menu and tap on open links in app.

This doesn't work, because no web page actually loads here. (If you e.g. view this bug and tap the URL in comment 0 and hit cancel on the dialog, you end up still looking at Bugzilla.)

> 2. Restart Firefox Android (swipe away and start again).

This does work, but it's not particularly discoverable or user-friendly.  Also: when exploring this bug, I noticed that some of the time, swiping away didn't actually seem to quit Firefox -- e.g. I'd swipe it away and then reopen Firefox, and it would come back up without needing to re-launch.

> Please confirm that one of these solutions works for you.

(2) sort of does butaas noted it's not great.

> The reason we didn't have any way of reverting your decision is because we wanted a simple solution without a big UI overhead. 

I understand that, but also recognize that this seems super-mysterious for the use-case where I tripped over this -- Firefox offers to open the external app once, and then never does again, which just looks like something's broken.

Maybe we could make our behavior here a bit more conditional on whether we think the user has "open in app" available in the Firefox menu?  If they do have that available, then blocking the dialog seems less troublesome since there's a discoverable workaround.  (This would address the scenario in bug 1830348 which was for Amazon, which does have an "open in app" option.)

RE "accidentally rejected" -- let me add one more more-realistic user-story here: in my real-world use-case, I didn't really "accidentally reject" the dialog.

Really, I saw the prompt, felt temporarily suspicious/paranoid, wanted to do some quick research before granting, and also wanted to see if I could still get where I needed after clicking cancel [e.g. if the web page provided some useful fallback instructions that didn't require this dialog].  Unfortunately, this particular website's failure-mode is **not** graceful; it doesn't even load a website.  It just checks your UA and (on Android devices) redirects to the URL `market://details?id=com.zvworkplace.member`

In reply to Roger Yang [:royang] from comment #5)
> There are two solutions if you accidentally rejected open links in apps.
> 1. Use the menu and tap on open links in app.

This doesn't work, because no web page actually loads here. (If you e.g. view this bug and tap the URL in comment 0 and hit cancel on the dialog, you end up still looking at Bugzilla.)

> 2. Restart Firefox Android (swipe away and start again).

This does work, but it's not particularly discoverable or user-friendly.  Also: when exploring this bug, I noticed that some of the time, swiping away didn't actually seem to quit Firefox -- e.g. I'd swipe it away and then reopen Firefox, and it would come back up without needing to re-launch.

> Please confirm that one of these solutions works for you.

(2) sort of does, but as noted, it's not great.

> The reason we didn't have any way of reverting your decision is because we wanted a simple solution without a big UI overhead. 

I understand that, but also recognize that this seems super-mysterious for the use-case where I tripped over this -- Firefox offers to open the external app once, and then never does again, which just looks like something's broken.

Maybe we could make our behavior here a bit more conditional on whether we think the user has "open in app" available in the Firefox menu?  If they do have that available, then blocking the dialog seems less troublesome since there's a discoverable workaround.  (This would address the scenario in bug 1830348 which was for Amazon, which does have an "open in app" option.)

RE "accidentally rejected" -- let me add one more more-realistic user-story here: in my real-world use-case, I didn't really "accidentally reject" the dialog.

Really, I saw the prompt, felt temporarily suspicious/paranoid, wanted to do some quick research before granting, and also wanted to see if I could still get where I needed after clicking cancel [e.g. if the web page provided some useful fallback instructions that didn't require this dialog].  Unfortunately, this particular website's failure-mode is **not** graceful; it doesn't even load a website.  It just checks your UA and (on Android devices) redirects to the URL `market://details?id=com.zvworkplace.member`

In reply to Roger Yang [:royang] from comment #5)
> There are two solutions if you accidentally rejected open links in apps.
> 1. Use the menu and tap on open links in app.

This doesn't work, because no web page actually loads here. (If you e.g. view this bug and tap the URL in comment 0 and hit cancel on the dialog, you end up still looking at Bugzilla.)

> 2. Restart Firefox Android (swipe away and start again).

This does work, but it's not particularly discoverable or user-friendly.  Also: when exploring this bug, I noticed that some of the time, swiping away didn't actually seem to quit Firefox -- e.g. I'd swipe it away and then reopen Firefox, and it would come back up without needing to re-launch.

(Also: when this "works", it subjectively feels like "Whelp, I guess Firefox broke. I'm glad I was able to get it working again by restarting it.")

> Please confirm that one of these solutions works for you.

(2) sort of does, but as noted, it's not great.

> The reason we didn't have any way of reverting your decision is because we wanted a simple solution without a big UI overhead. 

I understand that, but also recognize that this seems super-mysterious for the use-case where I tripped over this -- Firefox offers to open the external app once, and then never does again, which just looks like something's broken.

Maybe we could make our behavior here a bit more conditional on whether we think the user has "open in app" available in the Firefox menu?  If they do have that available, then blocking the dialog seems less troublesome since there's a discoverable workaround.  (This would address the scenario in bug 1830348 which was for Amazon, which does have an "open in app" option.)