1561022 - [meta] [about:addons] Investigate "handing off" AMO abuse reporting flow to Firefox about:addons

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement, P1)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

As an follow up to Bug 1540175, we want to evaluate the possibility of "handing off" to the Firefox abuse reporting integrated in the Firefox about:addons page also the abuse reports started from AMO.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

From a product perspective, here what we would like to see:

• We want to avoid anything that gives AMO potentially dangerous security privileges.
• Clicking on the Report Abuse button on AMO should start the abuse report flow currently in about:addons. Whether that should be a new tab, same tab, or some kind of popup is TBD.
• After finishing sending the report, it should be easy to get back to the page where the report initiated.
• If the report is for an extension that is installed, then all data should come from that extension.
• If the report is for an extension that isn't installed, then the data should come from AMO. Perhaps AMO should pass a metadata blob to about:addons to use for the report. I think the data required for the report is guid, name, developer, developer URL, icon, support email, and support URL. The install method should indicate the add-on isn't installed.

ni emanuela for UX input.

Comment 2

[emanuela [ux]]

+1 to all Jorge's point.

If for security reasons we can't show the modal like we do in about:addons, it'll be completly fine to start the reporting in the same tab.
After the user submit the report, we should display a thank you message (Thank you for submitting a report.) and here we can include the option to go back to the previous page.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: abuse_report_dialog_types.png

I've explored a bit a couple of possible implementation strategies, in particular:

• opening the panel as a popup panel (like a doorhanger but not anchored on a toolbar button)
• opening it into the "tabprompts" (similar to an alert / confirm tab modals, but showing the HTML abuse report panel instead)
• opening it into a new dialog window (similar to how we open some other dialog windows, e.g like we do for the prompt the user on blocklisted plugins or extensions (https://searchfox.org/mozilla-central/rev/34cb8d0a2a324043bcfc2c56f37b31abe7fb23a8/toolkit/mozapps/extensions/Blocklist.jsm#946-952)

Personally I think that the third option ("opening it as a new dialog window") would be the most reasonable one, especially because:

• it opens a window which is also tracked by the OS window management (and the OS will ensure that the user is aware about it, it will help the user to find it and select it, and we could allow the user to move and/or resize the dialog window if it doesn't fit into the screen space available to the user)
• it is already used for other similar dialogs (like the blocklist prompts as mentioned above, and so it will be a "less controversial proposal" then the other two)

The screenshot attached shows how a "dialog window" (on the left) or a "modal dialog window" (on the right) would look like on MacOS.

(In other operating systems they will likely be both rendered with the same look and feel, as a regular "dialog window" on MacOS, but in case of a modal window the user will not be able to trigger any UI element on the browser window that opened the modal until the modal window is being closed).

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

I would prefer to go non-modal because the flow has a bunch of clickable links, and the UX when they are clicked in a modal is kinda weird, at least on macOS. Let's wait for Emanuela's take, though.

Comment 5

[emanuela [ux]]

Thank you, Luca, for the screenshot.

My impression is that the modal keeps the context better. It's clear how it's coming from AMO.
Jorge, I would be curious to learn more about this weird experience with the links you mention above. Feel free to private message me about it.

Going with the dialog can also work, but we would need to add some context (e.g., the AMO's header) and remove some unnecessary UI like the closing button x on the right corner.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

Jorge, I would be curious to learn more about this weird experience with the links you mention above. Feel free to private message me about it.

I can't find an example of a modal like this in Firefox right now, but as an add-on dev I recall that clicking on a link in a modal on macOS would hide the modal, open a new tab with the link, and then bring the modal back. It looked pretty strange back then, but maybe that changed.

I agree the X should be removed, and I would argue it should be removed in both cases. I don't think the adding AMO header is necessary, though. I can see it being confusing if you change windows, forget it's there and then come back to it, but worse case scenario is the abuse report isn't sent, which isn't terrible.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Closing as fixed (all the dependencies has been closed and the feature is shipping in Firefox 71)