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
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
