924632 - Potentially separate state for "Prevent this page from creating additional dialogs" on alert/prompt/confirm, window.print, and window.showModalDialog

Status: RESOLVED WONTFIX

(Toolkit :: General, defect)

Description

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Selecting the "Prevent this page from creating additional dialogs" checkbox on an alert/prompt/confirm affects future alert/prompt/confirm calls on the page (which makes sense), but it also affects future window.print and window.showModalDialog calls (which perhaps makes less sense).

Similarly, if too many window.print calls are made, a prompt appears asking if you'd like to limit dialogs. If you choose to limit dialogs, that decision affects future alert/prompt/confirm calls, as well as window.print and window.showModalDialog calls.

We should consider separating the "dialogs prevented" state so that:
  - Selecting "Prevent this page from creating additional dialogs" on an alert/prompt/confirm affects ONLY future alert/prompt/confirm calls on that page.

  - Choosing to prevent future window.print calls (by selecting 'OK' in the prompt that appears) affects ONLY future window.print calls

  - Choosing to prevent future window.showModalDialog calls (by selecting 'OK' in the prompt that appears) affects ONLY future window.showModalDialog calls

Personally I prefer that we keep only one bit of state, i.e. keep the existing behavior, because adding the extra state complicates the logic around dialog abuse prevention and creates additional potential for dialog abuse. However, I don't call all the shots around here so I'm opening the bug for discussion :)

Comment 1

[Justin Dolske [:Dolske]]

(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #0)

> Personally I prefer that we keep only one bit of state

I agree. If a page is being sufficiently abusive so as to trigger the blocking (and the user chooses it), I'm not terribly worried about splitting hairs on what's being blocked.

I'd be fine with improving UI so that it's clearer that these things are being blocked, but that doesn't seem terribly pressing. And the user can always reload the page to reset dialog-blocking.

> However, I don't call all the shots around here so I'm opening the
> bug for discussion :)

Is there extra context or use-cases that are missing here? Otherwise I'm fine with wontfixing it.

Comment 2

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(In reply to Justin Dolske [:Dolske] from comment #1)
> Is there extra context or use-cases that are missing here? Otherwise I'm
> fine with wontfixing it.

This is follow-up from a dev.platform thread [1] and a #developers discussion that I haven't been able to successfully dig up from the logs, but I'll summarize:

  In bug 910501 we changed the meaning of the "Prevent this page from creating additional dialogs" checkbox from "rate-limit future dialogs on this page" to "prevent future dialogs on this page." As with any behavior change, there's the potential to break existing web sites. The specific concern that was raised was that the checkbox will break window.showModalDialog and window.print, when in the past it would have rate-limited them instead.
  If the patch in bug 910501 turns out to be breaking sites, we can choose to implement the behavior described in this bug instead of backing out 910501.

I think the right thing to do is WONTFIX this bug for now, and reopen it (or, more likely, forget that this one exists and open a new one) if we start to find negative consequences of the behavior change in bug 910501.

markh: I was going to add you to the CC list but it looks like you're already there. You raised the concerns initially - what are your thoughts on how to proceed?

[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/UZmSAOYTcVo

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Gavin convinced me that having discrete flags for each of the dialog types is somewhat overkill and will only affect a tiny minority of users using dialog-abusing sites.  So I'm now in basic agreement with comment 1.  Given no one else seems to be advocating for the behaviour described here, I'll WONTFIX it (but obviously anyone who disagrees should feel free to reopen)