Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Mon, Jun 27, 2011 at 15:36, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 27, 2011 at 3:17 PM, Alexey Proskuryakov a...@webkit.org 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 Sun, Jun 26, 2011 at 20:30, Ryosuke Niwa rn...@webkit.org 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 Mon, Jun 27, 2011 at 00:11, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 26, 2011 at 11:48 PM, Sreeram Ramachandran sree...@chromium.org 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
[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] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 12:10, Adam Barth aba...@webkit.org wrote: On Sun, Jun 26, 2011 at 11:42 AM, Alexey Proskuryakov a...@webkit.org 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
Re: [webkit-dev] The case for disallowing alerts in unload, redux
On Sun, Jun 26, 2011 at 13:19, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 26, 2011 at 12:38 PM, Sreeram Ramachandran sree...@chromium.org 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 13:40, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 26, 2011 at 1:37 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 26, 2011 at 1:34 PM, Sreeram Ramachandran sree...@chromium.org 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 19:08, Alexey Proskuryakov a...@webkit.org 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] Disallowing modal dialogs during unload events
On Thu, Apr 7, 2011 at 10:54, Maciej Stachowiak m...@apple.com 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
