This is a re-post from firefox-dev [3], in case anyone in dev-platform is aware of historical context. Please follow-up here in dev.platform (I think it's easier for users/mail-clients to jump into a newsgroup discussion than a mailing list discussion)

The test page at [1] illustrates the current behavior of the "Prevent this page from creating additional dialogs" checkbox. Here also is a brief description:
  1) If a dialog is shown and fewer than "dom.successive_dialog_time_limit" milliseconds have elapsed since the last dialog was closed, the "Prevent this page from creating additional dialogs" checkbox is added to the dialog
  2) If the user does not select the checkbox, go to 1
  3) If the user does select the checkbox, then future dialogs on the page are limited to a rate of 1 dialog per "dom.successive_dialog_time_limit" milliseconds (e.g. two consecutive alert() calls may result in {failure, success} if the first call occurs 2999ms after the last dialog closed, and the second call occurs 1ms later. In this case, "failure" means that an exception is thrown by alert())

This behavior is confusing to me - so confusing that I filed bug 910501 [2] without realizing that this is intended behavior. As a user, I expect that a checkbox labeled "Prevent this page from creating additional dialogs" will prevent the page from creating ANY additional dialogs, and so I would (and did) file a bug when that expectation isn't met. I think this is not just a wording issue: I much prefer the ability to disable all dialogs on a page than the ability to rate-limit dialogs on that page.

Of course, I don't speak for everyone, and I'm sure that there are reasons for the current behavior. I propose that we change the behavior of the "Prevent this page from creating additional dialogs" to prevent ALL subsequent dialogs on the page, but I'm interested in hearing ideas/arguments supporting the current behavior.

[1] https://bug856977.bugzilla.mozilla.org/attachment.cgi?id=806066
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=910501
[3] https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000955.html

I remember discovering some of this confusing behavior while working
on bug 391834. It dates back to bug 61098, and following the reasoning
from those bug comments is a bit tricky. jst or Natch might recall the
details, but I doubt it :)

I wouldn't really assume that there's some great reason for the
current behavior. I'm inclined to agree with you that we should just
simplify the code and the behavior.

Gavin
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

It doesn't seem like the timing was part of that bug. Initially, when I was
involved at least, the timing was used to set mDialogAbuseCount so that we
could track if there was an abuse at all. Once the abuse count was hit, we
prompted the user and, if the user so chose, disabled dialogs for the
duration of that nsGlobalWindow (top window, otherwise frames could be an
easy workaround). That was my intent as I recall, but things may have
changed since I was involved (either in the followup patches by jst or in
follow up bugs).

Natch.

On 18/09/2013 8:06 AM, Tim Abraldes wrote:
> This is a re-post from firefox-dev [3], in case anyone in
> dev-platform is aware of historical context. Please follow-up here
> in dev.platform (I think it's easier for users/mail-clients to jump
> into a newsgroup discussion than a mailing list discussion)

There are a few factors worth considering here.  Firstly, app-modal
dialogs are (IMO) far more hostile to the user than tab-modal ones -
app-modal dialogs prevent the user interacting with the browser, while
tab-modal ones still allow the user to close the offending tab.

I believe that "back in the day", alert/confirm/prompt were all
app-modal, but now they are tab-modal.  Thus, the considerations for
these calls aren't what they used to be - alert/confirm/prompt can't
prevent the browser from being interacted with.

That said though, there *are* other app-modal dialogs which still exist.
window.showModalDialog() (which IIUC, is already disabled in b2g and
Fennec) and window.print().

> The test page at [1] illustrates the current behavior of the "Prevent
> this page from creating additional dialogs" checkbox. Here also is a
> brief description:

Note that this demo page really isn't that user-hostile - the alert is
shown only for the tab and the tab can be closed.  If you switch away
from the tab there's no evidence of it abusing prompts.

However, if you modify that demo to do window.print() instead of alert,
it suddenly becomes *far* more hostile - the browser can't be interacted
with while the dialog is open, and the dialog continues to open even
when the tab is in the background.  IMO, this distinction is important.

> As a user, I expect that a checkbox labeled "Prevent this page from
> creating additional dialogs" will prevent the page from creating ANY
> additional dialogs,

While this makes sense to me at face value, I fear the subtleties of the
above might confuse the user.  If a page displays a few alerts and the
user selects "Prevent this page from creating additional dialogs", are
they really going to expect attempts to print the page to silently fail?
Similarly, if a dumb site required showModalDialog() to work correctly,
selecting that option on an alert() would break the site.

Note that the current behaviour does *not* break such sites.

IOW, the user's perception of "what is a dialog" might not match ours.
If a user selects "Prevent this page from creating additional dialogs"
while an alert dialog is up, they probably just mean "Prevent this page
from creating more alerts", not "Prevent this page from printing".  ie,
in the general case, I believe the user means "Prevent this page from
creating additional dialogs LIKE THIS".

I think it's reasonable to consider alert, confirm and prompt as the
same basic thing - so we only have 3 classifications of dialogs
(alert/confirm/prompt, window.print and window.showModalDialog) I wonder
if we could block dialogs per type?  ie, if you select "Prevent this
page from creating additional dialogs" while an alert is up,
alert/confirm/prompt are permanently blocked for the page - but
showModalDialog() or print() would still work.  Abusing print() would
block future print() calls, but not necessarily alerts.

That might still make the wording of the prompts a challenge, but I
think it would better meet the user's expectations while not breaking
sites in unexpected ways.

Mark

Separating and summarizing a little, it sounds like:

For alert/prompt/confirm, we're all (mostly?) agreed that the "prevent this page from creating additional dialogs" checkbox should have its meaning changed from "rate limit future alert/prompt/confirm" to "prevent future alert/prompt/confirm." In other words, bug 910501 is a valid bug.

For window.print(), we may want to consider a way to prevent the abuse of this function. A checkbox, similar to the one for alert/prompt/confirm, is a potential option. I imagine that making this a tab-modal dialog as opposed to an app-modal dialog would also be beneficial.

For window.showModalDialog(), same comments as for window.print().

If anyone has additional comments on point 1, I'd love to hear them as I have a patch that is waiting for the results of this discussion. As for points 2 and 3, I'd be happy to file bugs and/or start new dev.platform threads. Mark - let's coordinate here.

On 20/09/2013 5:36 AM, Tim Abraldes wrote:
> Separating and summarizing a little, it sounds like:
>
> For alert/prompt/confirm, we're all (mostly?) agreed that the
> "prevent this page from creating additional dialogs" checkbox should
> have its meaning changed from "rate limit future
> alert/prompt/confirm" to "prevent future alert/prompt/confirm." In
> other words, bug 910501 is a valid bug.

That bug doesn't include the subtlety that only alert/prompt/confirm
should be blocked - it just mentions "dialogs".  However, assuming that
additional constraint, then yeah, I do agree with it.

> For window.print(), we may want to consider a way to prevent the
> abuse of this function. A checkbox, similar to the one for
> alert/prompt/confirm, is a potential option. I imagine that making
> this a tab-modal dialog as opposed to an app-modal dialog would also
> be beneficial.
>
> For window.showModalDialog(), same comments as for window.print().

Note that these 2 functions already *do* hook into the same basic abuse
mechanism.  As it is non-trivial to add checkboxes to these dialogs (eg,
IIUC, the "print" dialog is the one provided by the OS on Windows), it
uses a simple confirm-style dialog just to ask the abuse question -
however, it still hooks into the same basic flags and timer reset
capabilities used for prompt/alert/confirm.

So while I agree conceptually with bug 910501, I think we should be very
careful about a solution there that would cause print or modal dialogs
to stop working because a user selected "prevent future dialogs ..."
when an alert was up. IOW, I think we need to fix bug 910501 without
regressing the useful aspects of the current behaviour.

Mark

I wrote a reply which I then accidentally sent only to Mark. In any case, we chatted in #developers about this.

I'm going to do the following:
  1. Update the patch in bug 856977 (dialogs shouldn't be possible during beforeunload) so that it doesn't affect the behavior of the checkbox
  2. Put the checkbox behavior changes into a patch in bug 910501 (checkbox should do what it says)
  3. File bugs about separating window.print() and window.showModalDialog() from alert/prompt/confirm (in terms of enabled/disabled state for a given page)

If we find that we like the behavior after landing 2, we may never actually implement 3. If we don't like the behavior, we can either go ahead and implement 3 or back out 2 without affecting 1.