1595091 - Evaluate to make the abuse report dialog not "always on top"

Status: VERIFIED FIXED

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

Description

[Victor Carciu]

Prerequisites :
extensions.abuseReport.amWebAPI.enable - true
extensions.abuseReport.url : https://addons-dev.allizom.org/api/v4/abuse/report/addon/
extensions.abuseReport.amoDetailsURL : https://addons-dev.allizom.org/api/v4/addons/addon/
extensions.abuseReport.openDialog - true

Steps to reproduce:
1.Load "https://addons.mozilla.org" in a new tab
2.Open the webconsole panel
call `await navigator.mozAddonManager.reportAbuse("worldwide@radio");
3.Wait for a report dialog window to be open and switch focus to another application (ie. Skype or anything else)

Expected results:
Skype app should be on top and users can go back to report abuse panel

Actual results:
Abuse report panel is always on top

NOTES:
Not reproducible on Mac where the panel can stay opened in background.

Comment 1

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

I'm not sure what options we have available on Windows. Is it possible to have the window be modal only to Firefox without impacting other application windows?

Comment 2

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

(In reply to Jorge Villalobos [:jorgev] (he/him) from comment #1)

I'm not sure what options we have available on Windows. Is it possible to have the window be modal only to Firefox without impacting other application windows?

Currently the abuse report dialog window is not opened as modal ([1]), it is currently just set as "alwaysOnTop", and so the OS is going to try to keep it on top of all other windows (but I'm not surprised that the platform-specific meaning for that may differ between Windows, MacOS and Linux).

Based on Victor comment, I guess that for MacOS that "alwaysOnTop" means "on top of all other windows from the same application" and on windows that may actually mean "on top of all other windows from any running application".

Nevertheless the user should still be able to move the window around and interact with other windows, or be able to move to another virtual desktop (which should also be available on Windows, at least on Windows 10).

Wouldn't that be enough for the rare case where a user may be interrupted by another application while submitting an abuse report?
Personally I wouldn't expect the users to keep that dialog window around for long (it should just take a few seconds to fill the report and press submit).

If we think that it may not be enough and we want to change the behavior experienced on Windows, I'm going to look into this asap (I think that one simple option would be to just remove the "alwaysOnTop", maybe just on Windows, but I want to actually reboot to windows and double-check what a user would experience with and without it).

[1]: one reason that made me opt for not making it a modal dialog is that the abuse report panel contains some links that the user may want to open, if we make the dialog modal we have to open a new Firefox window to open tabs on those links.

Comment 3

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

I'm not too worried about it because, like you said, it's an edge case and the abuse report dialog is meant to be something to be responded to quickly. However, "always on top" windows are certainly an annoyance, so if we can remove that restriction at least on Windows I'd be in favor of that.

Comment 4

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

Attachment: Bug 1595091 - Remove alwaysOnTop from the window features used by the abuse report dialog. r?mstriemer!

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62bdc9237377
Remove alwaysOnTop from the window features used by the abuse report dialog. r=mstriemer

Comment 6

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/62bdc9237377

Comment 7

[vcarciu]

Verified as fixed in FF 72.0a1 (2019-11-15) .

Abuse report is not "always on top" anynmore. I will attach a postfix screenshot.

Comment 8

[vcarciu]

Attachment: Postfix Screenshot

Comment 9

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

Comment on attachment 9108504 [details]
Bug 1595091 - Remove alwaysOnTop from the window features used by the abuse report dialog. r?mstriemer!

Beta/Release Uplift Approval Request

• User impact if declined: Without this change, the abuse report dialog window is always on top of any other windows (even other applications running at the same time).

During the QA verification happening on 71 Beta, we noticed that this behavior in some cases it may be a bit more annoying for a user (even if in most cases we expect this dialog window to don't stay around for long), and given that keeping it on top of any other windows is not strictly necessary we would prefer to let the users to freely use other applications and other Firefox windows without the need to move the dialog window aside.

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: It wouldn't be strictly necessary (the new behavior has been already verified on nightly, and the kind of change is not one that we could expect something different once uplifted on beta), nevertheless verify it is so quick that I wouldn't mind if QA could do it on Beta as well.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low / No risks. The patch is minimal and I wouldn't expect any regression risk from it (it just removing one of the windows feature used in a Services.ww.openWindow call), and it can't really affect anything else besides the abuse report dialog window.
• String changes made/needed:

Comment 10

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9108504 [details]
Bug 1595091 - Remove alwaysOnTop from the window features used by the abuse report dialog. r?mstriemer!

Low risk one line change, verified fir QA on Nightly, uplift approved for 71 beta 11, thanks.

Comment 11

[Oana Pop-Rus]

https://hg.mozilla.org/releases/mozilla-beta/rev/9ab34f36f017

Comment 12

[Victor Carciu]

Verified as fixed in FF 71.0b11