Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Mon, Jun 27, 2011 at 15:36, Ojan Vafai wrote: > On Mon, Jun 27, 2011 at 3:17 PM, Alexey Proskuryakov wrote: >> >> 27.06.2011, в 14:03, Darin Fisher написал(а): >> > I think we can make this behavior a Setting, and then certainly each >> > embedder of WebKit >> > can decide how prominently to surface this option. For Chrome, we'll >> > probably either make >> > it be a command line flag, or we would just leave out the option >> > entirely. >> >> Perhaps I'd be less unhappy about this change if the flag were off in >> layout tests, so that we didn't have to change them all to remove alert() in >> unload. > > That patch was scrapped. Now alerts during unload handlers will just log to > the console, so the alerts can be left in. The expected results for the > tests will change a bit though since the message being logged is different. Right. In addition, the proposed patch only enables this for chromium, so other ports are not affected. Can I get a review? http://webkit.org/b/56397 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Mon, Jun 27, 2011 at 00:11, Ryosuke Niwa wrote:
> On Sun, Jun 26, 2011 at 11:48 PM, Sreeram Ramachandran
> wrote:
>>
>> I think the performance benefit and reduction in code complexity are
>> secondary. Reducing user annoyance is the number one priority.
>
> But websites can annoy users by many other means. It seems like all we need
> is a "do not show again" checkbox rather than disallowing
> them indiscriminately.
Yes, websites can annoy users in many ways. Shouldn't we disable those
techniques we consider egregious, especially if they add little value
to the user or are universally disliked (cf: examples cited so far:
blink, popups)? In addition, users need the browser's help
particularly when they are trying to quit an annoying page, and the
page just won't let go. We already have the "do not show again"
checkbox. But clearly (from the stats in the original mail), there's
potential to do more.
As I said before, I haven't seen a case of anybody using a
confirm/prompt for a reasonable purpose in beforeunload. Here's an
example of the contrary, a site that pops up an alert in beforeunload:
http://www.80move.cn/
>> I'd prefer to keep things consistent and just disallow all modal dialogs
>> in all types of unload handlers (beforeunload, pagehide and unload).
>
> Why is that good or necessary?
> beforeunload and unload have very different semantics. beforeunload is
> fired before a page is unloaded to make the navigation cancelable and
> prepare for unloading the page whereas unload is fired AFTER the page
> dismissal has started. At this point, the navigation cannot be stopped and
> all script can do is to save states, etc...
> Given these semantics, it seems okay to disallow modal dialogs in unload
> event because the navigation cannot be canceled after unload event is fired
> and, in fact, browser has already started unloading the page. On the other
> hand, disallowing modal dialogs in beforeunload event seems weird to me
> because the navigation can still be canceled and the browser hasn't (and
> shouldn't have) started evicting the page.
I think the difference in semantics between beforeunload and unload is
perfectly captured by the return value. I don't see why other modal
dialogs enter into it. In fact, we've long recognized that people can
abuse beforeunload/unload in various ways and we've taken steps to
mitigate them:
1. Developers have tried to abuse the return string from beforeunload
to confuse users and click on the wrong button. So much so that
Firefox has ended up not showing the return string altogether, which I
think moves the needle too far in the other direction (see the long
list of comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=588292). I think our
compromise of showing the return string, but making the buttons
unambiguous ("Stay/Leave" instead of "OK/Cancel" or "Yes/No") is the
right balance.
2. Developers have tried to put long delays in unload and sleeping
forever (and indeed, avoiding the script-hang-monitor timeout). We've
hacked around them (http://webkit.org/b/29193, http://crbug.com/7823,
https://lists.webkit.org/pipermail/webkit-dev/2009-September/009925.html).
3. Developers try to load resources, navigate to other pages, etc. We
rightly block such attempts from unload. However, there's a legitimate
need to send pings for analytics, so we compromise by allowing image
requests to outlive the page (http://webkit.org/b/30457).
To summarize, each of the above can be considered a legitimate
developer need, but we find that more often than not, they are abused.
In many cases, we have been able to support the legitimate use case by
offering a compromise. I consider disallowing modal dialogs but
allowing the return value to popup the stay-or-leave dialog to be a
similarly good compromise between the needs of developers and users.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 20:30, Ryosuke Niwa wrote: > I've started to think that we should just kill modal dialogs in unload event > and leave modal dialogs during unbeforeload and other events alone. While > things happen in unload isn't guaranteed to run before the page is evicted > (navigated), beforeunload is guaranteed to happen before the navigation, and > there seems to be a valid use case of modal dialogs during the event. > In fact, if the motivation was to close a window/tab quickly, then there's > no benefit in disabling modal dialogs in beforeunload because we'll have to > wait until the event handler finishes running anyways. I think the performance benefit and reduction in code complexity are secondary. Reducing user annoyance is the number one priority. Allowing modal dialogs during beforeunload doesn't help with that. I'd prefer to keep things consistent and just disallow all modal dialogs in all types of unload handlers (beforeunload, pagehide and unload). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 19:08, Alexey Proskuryakov wrote: > > 26.06.2011, в 12:10, Adam Barth написал(а): > >>> Interesting - this is much more than I expected , too. So, authors are >>> widely using alerts in onload, and breaking those would be bad for >>> compatibility. If this change is made, 2.3% of users will suffer every week. >> >> It would be useful to know what fraction of those users would have a >> better experience with this change. Sreeram, of the example sites >> that you've seen, how many would be improved by suppressing these >> alerts? > > > I'm not sure if historically browsers were often taking the liberty of > crippling widely used features in this way. We didn't kill marquee, for > instance. For another example, I know that a lot of users dislike animated > GIFs, and yet we haven't removed support for those. Yet, we killed the blink tag and block popups. I don't think there's a clear consistency here. Some things we deem to have crossed the line, some we don't. In this case, Ian Hickson has suggested that blocking alerts might be worth codifying into the standard (https://bugs.webkit.org/show_bug.cgi?id=56397#c15). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 13:40, Ryosuke Niwa wrote:
> On Sun, Jun 26, 2011 at 1:37 PM, Ryosuke Niwa wrote:
>>
>> On Sun, Jun 26, 2011 at 1:34 PM, Sreeram Ramachandran
>> wrote:
>>>
>>> A confirm() can't actually do the first option ("Don't leave"). I
>>> believe there's nothing a page can do to prevent the navigation once
>>> it is in unload. The only way it can prevent it is by installing a
>>> beforeunload and returning a string.
>>
>> Right. So a web page can first ask whether a user wants to save states or
>> not. Then ask whether a user really wants to leave a page or not using
>> beforeunload.
>
> To further clarify, it doesn't even have to use beforeunload. The important
> thing is that if we disallow confirm in beforeunload, unload, etc... then
> web apps will have no way of asking a user if he/she wants to save states.
The problem is that if we disallow alerts, but not confirm/prompt,
webpages will just gravitate to using confirm() to annoy the user. As
I said, the only uses of confirm() I actually saw were of this type
already. Those who wanted to save state are already doing it without
asking the user for explicit confirmation.
If the argument is purely that somebody _might_ want to use it, since
confirm/prompt functionality can't be exactly duplicated in another
way, then I submit the case of showModalDialog(). Certainly you can do
things with showModalDIalog() (such as popping up a form with the
state, allowing the user to edit and submit) that can't be done with
alert/confirm/prompt. However, we already disallow these, since by
default, popup blocking kills these. I don't see anybody championing
the need of developers to be able to use showModalDialog, because we
recognize that they are extremely annoying, especially when you are
trying to leave a page.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 13:19, Ryosuke Niwa wrote:
> On Sun, Jun 26, 2011 at 12:38 PM, Sreeram Ramachandran
> wrote:
>>
>> I did see a couple of confirm() calls in beforeunload. The examples I
>> found were also annoying ("Are you sure you want to leave? Yes/No"),
>> but I can imagine those could instead have been more useful ("Do you
>> want to save some state? Yes/No"). I think if there are indeed such
>> uses, they can be transformed into something that returns a non-NULL
>> value in beforeunload and then saves state.
>
> "Do you want to save some state? Yes/No" seems like a valid use of confirm
> because there are 3 possible actions users can take:
>
> Don't leave
> Save state and leave
> Discard state and leave
A confirm() can't actually do the first option ("Don't leave"). I
believe there's nothing a page can do to prevent the navigation once
it is in unload. The only way it can prevent it is by installing a
beforeunload and returning a string.
I do see that there can be potential uses for confirm and prompt
during page dismissal. However, I haven't seen any such uses in my
manual inspection; also, the number of such instances in the
histograms is very tiny (orders of magnitude smaller than alert()).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 12:10, Adam Barth wrote:
> On Sun, Jun 26, 2011 at 11:42 AM, Alexey Proskuryakov wrote:
>> 26.06.2011, в 09:34, Sreeram Ramachandran написал(а):
>>> Briefly, from a histogram we added a while ago, I find that 2.3% of
>>> all users encounter at least one such modal dialog every week. This is
>>> much larger than I expected.
>>
>> Interesting - this is much more than I expected , too. So, authors are
>> widely using alerts in onload, and breaking those would be bad for
>> compatibility. If this change is made, 2.3% of users will suffer every week.
>
> It would be useful to know what fraction of those users would have a
> better experience with this change. Sreeram, of the example sites
> that you've seen, how many would be improved by suppressing these
> alerts?
Every single manual example of alert I found was of the annoying
variety ("Please don't go!", "Thanks for checking our site!", "Be sure
to click Yes on the next dialog!", etc). None of them add any
functionality. Indeed, how can they? They are just messages with a
single "OK" button to dismiss them.
I did see a couple of confirm() calls in beforeunload. The examples I
found were also annoying ("Are you sure you want to leave? Yes/No"),
but I can imagine those could instead have been more useful ("Do you
want to save some state? Yes/No"). I think if there are indeed such
uses, they can be transformed into something that returns a non-NULL
value in beforeunload and then saves state.
In fact, I found many more cases where on unload, the pages
automatically cleared some state, set some cookies, sent some pings,
etc., without ever alerting or asking the user. I believe, for
instance, that Gmail does this currently: If you are editing a message
and abruptly close the window, it just saves the draft automatically,
without bothering the user.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] The case for disallowing alerts in unload, redux
We've discussed this in the past (https://lists.webkit.org/pipermail/webkit-dev/2011-April/016431.html). That thread ended with a call for data. Today, I bring examples and statistics. Briefly, from a histogram we added a while ago, I find that 2.3% of all users encounter at least one such modal dialog every week. This is much larger than I expected. I think it means that it's not just web developers who encounter them while debugging their pages. To me, this makes a very strong case for disallowing them. Here are some examples of sites that show an alert when their pages are unloaded: http://ddl.vidplayer.net/ http://www.buenosprofesionales.com/ http://www.watchsaleshop.com/ http://52-teurseu.blogspot.com/ http://aaz-armor.blogspot.com/ The last two sites above are just two examples out of hundreds of such blogs. Of course, alerts are also used for debugging. The proposed patch in https://bugs.webkit.org/show_bug.cgi?id=56397 turns alerts into console messages. Console messages can now be made to persist across page loads, so I think this helps address the debugging use case. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disallowing modal dialogs during unload events
On Thu, Apr 7, 2011 at 10:54, Maciej Stachowiak wrote: > Is there data on: > - The user impact of modal dialogs being fired from before unload, unload or > page hide - how often does this happen? > - The Web compatibility impact of removing this functionality (are the sites > that do it using it for seemingly legitimate reasons)? Sorry, I don't have any data at the moment (actually, I don't even have any examples). > I can think of two ways to gather the data: > 1) Add some form of opt-in tracking to see how often users hit a modal dialog > during an unload event, and sites where this is done, so we could determine > if it causes breakage. We can collect aggregate stats from Chromium, but our privacy policy won't let us collect specific URLs or sites. So, even if we found that a very small percentage of users are affected by this, we won't be able to tell which sites they were on, or whether the dialogs were necessary or annoying. > 2) Run automated Web crawlers to find this out. I'll try, but static analysis of js is hard/impossible; but perhaps I'll be able to find at least a couple of examples. > Since we have a potential tradeoff between Web compatibility and usability, > it would be good to get some data so that we can weigh the tradeoff. > > Side note: when I see a dialog upon leaving a webpage, it is almost always > the beforeunload dialog. I'm not sure I have ever seen a regular alert, > prompt, confirm, or showModalDialog when leaving the page. This is part of > why I'd like to see data. Would we be solving a real problem with this > change, or just a theoretical one? As agreed on #webkit, we'll proceed by enabling this in chromium and collecting some aggregate stats (for whatever that's worth), relying on bug reports to find any specific issues that arise. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Disallowing modal dialogs during unload events
We'd like to disallow modal dialogs (i.e., those arising from calls to alert, confirm, prompt or showModalDialog) during unload events (beforeunload, unload and pagehide) [1]. Chromium wants to do this [2]. Since this affects web compatibility, I'd like to get agreement from the other webkit ports as well. The benefits are: + Fewer annoyances for users who are trying to leave a page. + In the case of tab close, allows the browser to hide the tab before it has finished running the unload or pagehide event handlers (doesn't apply to beforeunload); gives the impression of better performance. This doesn't affect returning a non-null value from beforeunload; that will still cause the browser to show the stay-or-leave dialog. We think that is sufficient to satisfy legitimate needs to warn the user about data loss, etc. Outside webkit, this has been discussed on whatwg, but without a definite conclusion [3]. Firefox seems to be considering this as well [4]. All in favour, say aye! [1] https://bugs.webkit.org/show_bug.cgi?id=56397 [2] http://code.google.com/p/chromium/issues/detail?id=68780 [3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025080.html [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
