1803589 - Allow users to submit site support requests for cookie banners in Focus

Status: REOPENED

(Focus :: General, task, P2)

Description

[Arturo Mejia [:amejia]]

See the desktop version of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1801971

Comment 1

[Chris Peterson [:cpeterson]]

We're still waiting for UX design.

Comment 2

[Arturo Mejia [:amejia]]

We will need to do some investigation on how we are going to collect the data, this document captures the requirements on how it should be done using Glean.

Comment 3

[Arturo Mejia [:amejia]]

Attachment: Site not supported request.png

When an use navigates to a site that is not supported by cookie banner handle, we would like to show two buttons "Cancel" and "Request support" in the inner panels, to indicate the user want to request the actual site to be added.

Designs

Comment 4

[Iorga Gabriel]

Depends on https://bugzilla.mozilla.org/show_bug.cgi?id=1819652

Comment 5

[Iorga Gabriel]

This the pull request .

Comment 6

[BMO Github Automation]

Authored by https://github.com/iorgamgabriel
https://github.com/mozilla-mobile/firefox-android/commit/ea8683125efcd8c35747da5280b1053f729a8f12
[main] Bug 1803589 - Implement submit site support requests for cookie banners in Focus

Comment 7

[miralobontiu]

Attachment: site not supported.png

Verified on a local build of Focus Nightly 113.0a1 from 3/22, with Samsung Galaxy Note 8 (Android 9), Lenovo tablet M10 (Android 10), and Oppo Find X3 Lite (Android 11).

Tested on the https://remolacha.net/ website. After submitting the request to support the Cookie Banner Reduction, the ETP panel did not display the "Request to support site submitted" message under the CBR.

I'll remove the qe-verify+ label, and reopen the bug, because it is partially resolved.

Comment 8

[Iorga Gabriel]

Changes after design review
https://docs.google.com/document/d/1CstQ0eds7rPxtyYLpw4G4QKqV_qIufB4oWfDyydPVss/edit

Comment 9

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1803589 - Changes after design review. (#1457)

Comment 10

[Chris Peterson [:cpeterson]]

The Android team has not been keeping our P1 bug list up to date, so we're resetting all our P1 bugs to P2 to avoid signalling that we're actively working on bugs that we're not. The BMO documentation https://wiki.mozilla.org/BMO/UserGuide/BugFields#priority says P1 means "fix in the current release cycle" and P2 means "fix in the next release cycle or the following (nightly + 1 or nightly + 2)".

If you are actively working on this bug and expect to ship it in Fx 122 or 123, then please restore the priority back to P1.