1668043 - It should not be possible to interact with the tab content (e.g. using find-in-page) while tab-modal Print UI is open

Status: NEW

(Toolkit :: Printing, defect, P3)

Description

[Jonathan Kew [:jfkthame]]

When the tab-modal print UI is open, the content area of the tab behind it (much of which is hidden by the print panel, depending on window size) is greyed-out and inactive; it does not respond to clicks, scroll gestures, etc.

However, rather surprisingly, it is still possible to interact with the tab content in indirect ways, such as using the Find bar to search in the content, or modifying a #fragment in the URL bar to jump to a new scroll position.

IMO such interactions should be blocked while the print UI is open.

(I think it's questionable whether the user should be able to navigate to a new page in the tab while this "tab-modal" UI is open, but at least in that case we dismiss the dialog -- see bug 1657508.)

Comment 1

[Blake Winton (:bwinton) (:☕️)]

(This might be a more general problem with TabDialogBox… Should we let people interact with the underlying page for, say, the HTTP Auth dialog?)

Comment 2

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #0)

IMO such interactions should be blocked while the print UI is open.

It's really not obvious to me what this is going to mean in practice.

In particular, some of it may be obvious (e.g. "disable opening the find bar") but some of it also isn't (e.g. if the find bar is already open, should it be closed? If the user types a new fragment and hits enter, should we thow away their user input on enter? What else?)

I'm also worried about this becoming a game of whack-a-mole - e.g. if you print a page before opening picture-in-picture, does the video keep playing? What happens if you interact with the PiP controls or pop it back into the page? Can you save the page using save-page-as while the dialog is up? Inspect it with devtools? (should PiP/devtools close when you attempt to print?)

This probably needs some UX input.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs (he/him) from comment #2)

(In reply to Jonathan Kew (:jfkthame) from comment #0)

IMO such interactions should be blocked while the print UI is open.

It's really not obvious to me what this is going to mean in practice.

Agreed, there are probably lots of questions to consider here...

In particular, some of it may be obvious (e.g. "disable opening the find bar") but some of it also isn't (e.g. if the find bar is already open, should it be closed? If the user types a new fragment and hits enter, should we thow away their user input on enter? What else?)

My suggestion: yes, probably disable opening the find bar; if it's already open, the find bar itself is disabled so that it will not respond to any user input. From a user's point of view, it's associated with the (currently-disabled) content, so while the modal UI blocks interaction with the content, it should also block interaction with the find bar.

I'm also worried about this becoming a game of whack-a-mole - e.g. if you print a page before opening picture-in-picture, does the video keep playing? What happens if you interact with the PiP controls or pop it back into the page? Can you save the page using save-page-as while the dialog is up? Inspect it with devtools? (should PiP/devtools close when you attempt to print?)

If you have a PiP video open, it's currently unaffected by opening the print UI, and you can still interact with the PiP controls; that seems reasonable to me, given that it's been separated from the tab where the modal UI is showing. If you pop it back into the page, though, you can't do anything further with it until the modal UI is dismissed.

Save Page As seems acceptable, as it doesn't manipulate the (blocked) tab, it just saves a copy of its contents. And devtools remaining available also seems OK to me. It's true that opening/closing devtools may cause the tab contents to shift around, but that's more comparable to resizing the window than to directly interacting with the content.

This probably needs some UX input.

+1 to that! Comments above are just some initial thoughts as to what makes sense to me.

Comment 4

[Walter K.]

See also Bug 1668855 for page Zoom in/out shortcuts

Comment 5

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)

If you have a PiP video open, it's currently unaffected by opening the print UI, and you can still interact with the PiP controls; that seems reasonable to me, given that it's been separated from the tab where the modal UI is showing. If you pop it back into the page, though, you can't do anything further with it until the modal UI is dismissed.

Visually it's separate, but playing/pausing the pip video plays/pauses the video in the website's DOM (we just forward the visual bits of the stream into the separate window) which is web-observable via DOM events (though I guess we don't dispatch them or something while printing? I'm not sure without testing.)

Edit: Oh, and the PiP shortcut still "works" while the print dialog is up, and pops up a black window without a video. :-(

Comment 6

[Blake Winton (:bwinton) (:☕️)]

(Moving bugs to 86, part 1.)

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Moving things to 88, cause we're mostly on Proton these days…

Comment 8

[Samuel Saveme]

Attachment: same problem

Thanks from renriralco1974.