1544698 - "Allow" button is inactive when "Don't ask again" checkbox is checked

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Mira Lobontiu (Android QA)]

Attachment: 2019_04_16_11_05_43.mp4

Devices:

• Samsung Galaxy Tab S3 (Android 8.0);
• Huawei MediaPad M3 (Android 7.0);
• Sony Xperia Z5 (Android 7.0);

Builds:

• Nightly 68.0a1 (2019-04-14);
• Beta 67.0b11;
• Release 66.0.2;

Steps to reproduce:

1. Go to https://mozilla.github.io/webrtc-landing/gum_test.html.
2. Tap on "Audio&Video" button.
3. When the permissions menu is displayed, check the "Don't ask again" checkbox, then "Allow" button.

Actual result:
"Allow" button becomes inactive after "Don't ask again" checkbox is checked and cannot be tapped. Only "Deny" button is active.

Expected result:
The user should be able to tap on the "Allow" button after the checkbox "Don't ask again" is checked.

Notes:
Not reproducible on Nokia 6 (Android 7.1.1).

Comment 1

[Diana Iacos]

I’ve investigated this bug and these are the following results:
For almost all devices android runtime permission works in this way:
-> First time, when we request a permission the system will show the permission dialog (a standard Android dialog, which we cannot customize) without “Don’t ask again” checkbox.
-> If all are accepted, then everything goes normally.
-> But after one or all permissions was denied when the system will show again the permission dialog the “Don’t ask again” checkbox will appear.
-> If any of the permission has been denied with “Never ask again” check, then that permission can only be allowed from the Settings of the app. (If “Don’t ask again” it’s checked “Allow” button will be disable.)

But on some devices the behavior it’s differently: ex Nokia 6 / TA-1000 (Android version 7.1.1)
-> “Don’t ask again” checkbox is always present in permission dialog
-> When “Don’t ask again” it’s checked “Allow” button is not disable like on others devices.

We can’t control these system's behaviors, so we can’t do anything here. After consulting with Mira I’m closing the bug as INVALID.