1686081 - Hide content prompts when opening tab prompts

Status: NEW

(Toolkit :: Content Prompts, defect, P2)

Description

[Micah [:mtigley] (she/her)]

We might want to consider hiding a prompt that is opened on the content level (i.e: via alert(), prompt(), etc...) when a tab prompt is opened (i.e: when the user wants to print a page).

I think one question I have about this is if we have any cases where the user would need to have both modal types displayed?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Romain Testard [:RT]]

Marking as P1. Per experience review we agreed to mark as P1 bug the ones that will block MR1.

Comment 3

[:Gijs (he/him)]

(In reply to Micah Tigley [:mtigley] from comment #0)

We might want to consider hiding a prompt that is opened on the content level (i.e: via alert(), prompt(), etc...) when a tab prompt is opened (i.e: when the user wants to print a page).

I think one question I have about this is if we have any cases where the user would need to have both modal types displayed?

Paul, do you have an intuition about this? What do we do here right now, and what do you think the ideal state is?

Comment 4

[Paul Zühlcke [:pbz]]

Switching over some of the window prompts to be embedded (on tab level) a while ago, we didn't run into any conflicts. I'm currently not aware of any cases where a content prompt would depend on a tab or embedded window prompt somehow.

When we showed window prompts for anything not content they always had priority / were shown in front. I think it makes sense to keep this behavior for the tab and the embedded window prompts
The order should be window > embedded window (gDialogBox) > tab dialog > (TabDialogBox) > content dialog. Chrome consumers should be mindful of this precedence.
Whether we want to just overlay, or temporarily hide the underlying prompts is a UX consideration. I'm in favor of overlaying.

Comment 5

[:Gijs (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #4)

Switching over some of the window prompts to be embedded (on tab level) a while ago, we didn't run into any conflicts. I'm currently not aware of any cases where a content prompt would depend on a tab or embedded window prompt somehow.

When we showed window prompts for anything not content they always had priority / were shown in front. I think it makes sense to keep this behavior for the tab and the embedded window prompts
The order should be window > embedded window (gDialogBox) > tab dialog > (TabDialogBox) > content dialog. Chrome consumers should be mindful of this precedence.
Whether we want to just overlay, or temporarily hide the underlying prompts is a UX consideration. I'm in favor of overlaying.

I think this is what we're doing today, right? So perhaps this is WFM?

Comment 6

[Paul Zühlcke [:pbz]]

Yes, the order is what I described. However we have mixed behavior for overlaying / hiding:
"Tab" overlays "content" level, but gDialogBox hides both tab and content level. Do we want to make this more consistent, or is there a specific reason why gDialogBox hides all other dialogs? Maybe this is something we can figure out in this bug.

Comment 7

[:Gijs (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #6)

Yes, the order is what I described. However we have mixed behavior for overlaying / hiding:
"Tab" overlays "content" level, but gDialogBox hides both tab and content level. Do we want to make this more consistent, or is there a specific reason why gDialogBox hides all other dialogs? Maybe this is something we can figure out in this bug.

I deliberately did this in https://phabricator.services.mozilla.com/D103388 - I don't recall if there was discussion around this at the time and I certainly can't find it now. :-(

For clarity:

(In reply to Paul Zühlcke [:pbz] from comment #4)

When we showed window prompts for anything not content they always had priority / were shown in front. I think it makes sense to keep this behavior for the tab and the embedded window prompts
The order should be window > embedded window (gDialogBox) > tab dialog > (TabDialogBox) > content dialog. Chrome consumers should be mindful of this precedence.
Whether we want to just overlay, or temporarily hide the underlying prompts is a UX consideration. I'm in favor of overlaying.

Katie, can you confirm what behaviour we would want here? The issue is that we have different "levels" of prompts:

• prompts in the webpage (e.g. on this webpage, if you open the web console, type in alert('hi') and hit enter, that kind of thing)
• prompts that are tab-specific (e.g. if you put https://jigsaw.w3.org/HTTP/Basic/ in the location bar)
• prompts that are window-specific (e.g. if you close the window with more than 1 tab open and you have the tab close warning turned on)

and the question is whether, if a higher priority dialog appears, we should temporarily hide the lower priority dialog while the higher priority one is up, or keep the lower priority one visible, greyed out, behind the mask/overlay that we use for the higher priority dialog. Can you confirm what you'd expect?

(I'm out for a bit, if you have questions please chat with Micah or Paul. :-) )

Comment 8

[katieC]

Attachment: Screenshot_AvoidLayeredModals.png

Hide is the expected ux behaviour - based on the higher priority messages mentioned above. Only show one modal at the time, (user’s triggered modals have priority over others). Once the action is done, show the second most important and so on. The risk, otherwise, is introducing overlapping modals and obscuring messaging (modal lasagna is not good - see attached screenshot).