This is similar issue http://bugzilla.mozilla.org/show_bug.cgi?id=1366818

The issue involves a potential conflict of events in the code, allowing the simultaneous execution of various actions such as mouse cursor capture, activation of fullscreen mode, and form message output. As a result, when the form is called, the message may appear beyond the screen area, leading to undesirable consequences.

The continuous invocation of the form interferes with pressing the Escape button, causing significant irritation to the user. In the mobile version, the behavior resembles a DOS attack since, in most cases, it is challenging to close the print invocation, forcing the user to close the browser.

Cross notifications are blending, and the cursor capture notification does not appear. Coordination and proper event management are necessary to prevent this undesirable interaction

The print.html test case didn't seem to do much for me on MacOS. The printing dialog didn't appear until after I'd left full screen. The full screen from the deathline test case was harder to break out of, though I was able to finally do it if I spammed the escape key. I'm not sure if this is related to some of our existing user activation issues or not.

(In reply to Andrew McCreight [:mccr8] from comment #5)

The print.html test case didn't seem to do much for me on MacOS. The printing dialog didn't appear until after I'd left full screen. The full screen from the deathline test case was harder to break out of, though I was able to finally do it if I spammed the escape key. I'm not sure if this is related to some of our existing user activation issues or not.

To enable fullscreen mode for print.html, press the Escape key and click anywhere on the screen. I suggest removing cursor capture so that printing can be activated in fullscreen mode without additional clicks.

I noticed that the pop-up notification can overlap notifications about entering fullscreen mode. It cannot fake the message, but it also shouldn't cover it. If you exit fullscreen mode and then click the browser refresh icon, the script will run without user interaction.

I think it's worth refining the form for sending pop-up windows, require user interaction or limit window manipulations. If the whole problem is due to too frequent calling via setInterval. If we consider Chrome, then its engine does not have a binding of notifications to the pressing of other keys.

Edgar, is this something you could look at eventually? Thanks. It seems kind of nasty.

(In reply to Raphael from comment #0)

In the mobile version, the behavior resembles a DOS attack since, in most cases, it is challenging to close the print invocation, forcing the user to close the browser.

In desktop version, use still can interact with browser and close the problematic tab. I filed bug 1895214 for the mobile version.

(In reply to Raphael from comment #7)

If you exit fullscreen mode and then click the browser refresh icon, the script will run without user interaction.

I think this is the same as bug 1872841.

This bug contains many different things, I filed and linked other bugs for them (see comment #10 and comment #11).

I think the major issue of this bug is that the form validation popup could block pressing ESC key to exit fullscreen. User can still press ESC rapidly many times to make it work, or use some other way to exit fullscreen, e.g. Alt/command + <number> to switch to another tab etc. But anyhow, form validation popup should not block ESC key to exit fullscreen. I am going to try to fix this here.

(In reply to Edgar Chen [:edgar] from comment #10)

(In reply to Raphael from comment #0)

In the mobile version, the behavior resembles a DOS attack since, in most cases, it is challenging to close the print invocation, forcing the user to close the browser.

In desktop version, use still can interact with browser and close the problematic tab. I filed bug 1895214 for the mobile version.

Can I get access to this bug?

(In reply to Raphael from comment #15)

In desktop version, use still can interact with browser and close the problematic tab. I filed bug 1895214 for the mobile version.

Can I get access to this bug?

I cc-ed you there.

http://hg.mozilla.org/mozilla-central/rev/18f242a4688e

Do you think this patch might cause the following regression?

Perfherder has detected a build_metrics performance change from push cd09151a1c46cba9d56b45684eebc6465a5e869c.

Regressions:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run these tests on try with ./mach try perf --alert 632

For more information on performance sheriffing please see our FAQ.

(In reply to Florin Bilt from comment #19)

Perfherder has detected a build_metrics performance change from push cd09151a1c46cba9d56b45684eebc6465a5e869c.

Hi Florin, the push log points to bug 1898214, maybe you commented on the wrong bug?

(In reply to Edgar Chen [:edgar] from comment #20)

(In reply to Florin Bilt from comment #19)

Perfherder has detected a build_metrics performance change from push cd09151a1c46cba9d56b45684eebc6465a5e869c.

Hi Florin, the push log points to bug 1898214, maybe you commented on the wrong bug?

I know that alert is linked to another bug, but I also suspect that this bug might have contributed to the alert as well. The graph is very unclear, which is why I decided to ask for help. Just to be sure that the alert is not generated by this bug.

(In reply to Florin Bilt from comment #21)

I know that alert is linked to another bug, but I also suspect that this bug might have contributed to the alert as well. The graph is very unclear, which is why I decided to ask for help. Just to be sure that the alert is not generated by this bug.

Thanks for clarifying. It doesn't seem like it is from here to me. This bug doesn't add much code.