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
Re: [webkit-dev] The case for disallowing alerts in unload, redux
26.06.2011, в 19:37, Sreeram Ramachandran написал(а): 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). These examples are both somewhat different from blocking alerts as proposed: - Killing blink hardly removed any semantic meaning from pages. - Killing pop-ups did, so browsers have super accessible preferences and/or notifications for that. Note how Safari has the preference right in application menu. Perhaps the pop-up preference should be extended (and renamed) to cover the proposed behavior? - WBR, Alexey Proskuryakov ___ 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 1:40 PM, Alexey Proskuryakov a...@webkit.org wrote: 26.06.2011, в 19:37, Sreeram Ramachandran написал(а): 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). These examples are both somewhat different from blocking alerts as proposed: - Killing blink hardly removed any semantic meaning from pages. - Killing pop-ups did, so browsers have super accessible preferences and/or notifications for that. Note how Safari has the preference right in application menu. Perhaps the pop-up preference should be extended (and renamed) to cover the proposed behavior? That sounds like an application-level decision. In any case, I agree with Darin that the next step here is to try it in a dev channel release. Adam ___ 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 1:40 PM, Alexey Proskuryakov a...@webkit.org wrote: 26.06.2011, в 19:37, Sreeram Ramachandran написал(а): 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). These examples are both somewhat different from blocking alerts as proposed: - Killing blink hardly removed any semantic meaning from pages. - Killing pop-ups did, so browsers have super accessible preferences and/or notifications for that. Note how Safari has the preference right in application menu. Perhaps the pop-up preference should be extended (and renamed) to cover the proposed behavior? - WBR, Alexey Proskuryakov I don't understand the comparison you are making. Popups are/were way more common than alerts generated from unload. Way, way more common. You mentioned marquee earlier. That was only added by the Gecko engineers because their arms were twisted by management. So sad. There are plenty of other IE'isms that we did not implement, despite suffering web compat problems. I'm pretty surprised that you are so concerned about this change. It seems like we have learned that alerts in unload handlers are not very common. Yes, they are more common than expected, but upon closer inspection the usage is poor (trying to prevent users from leaving a site). For multi-process browsers, we see a big benefit to be had by disallowing these dialogs. It would potentially allow us to hide tabs immediately when the user closes them. We would no longer need to keep the tab visible while we wait for the unload handler to run. Keep in mind that in a multi-process browser, the tab being closed could be bound to a process that is entirely swapped out. Paging it in to run unload handlers could be very costly. Alternative solutions, like bringing the hidden tab back into view when it pops up an alert, are not satisfactory either. That leads to ripping the user's focus away from what they want to do next. That's not good UI. 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. Regards, -Darin ___ 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
27.06.2011, в 14:03, Darin Fisher написал(а): I'm pretty surprised that you are so concerned about this change. I dislike magic APIs that work sometimes, but not always. In this case, the reason for crippling the API seems to be almost entirely about implementation issues - the discussion about whether it's good for improving user experience goes in rounds, possibly because anyone who wants to annoy users can just switch to beforeunload. 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. - WBR, Alexey Proskuryakov ___ 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 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. ___ 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
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. - WBR, Alexey Proskuryakov ___ 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 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? Adam ___ 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 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: 1. Don't leave 2. Save state and leave 3. Discard state and leave If the site just used beforeunload, it can't distinguish 2 and 3. - Ryosuke ___ 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 1:34 PM, Sreeram Ramachandran sree...@chromium.orgwrote: 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. 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()). Maybe we should just kill alert then. - Ryosuke ___ 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 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. - Ryosuke ___ 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 1:40 PM, 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. Why can't the app just return a string from the beforeunload handler? That's the usual way of handling this situation. Adam ___ 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 1:53 PM, Sreeram Ramachandran sree...@chromium.orgwrote: 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. Thanks for gathering that data. It sounds to me like the next step is to push out a version of Chrome to the dev channel that disallows alert, confirm, prompt during unload and beforeunload. Then, let's see if we get any bugs filed against Chrome by users who feel that this change impairs their usage of a web site. I suspect the only bug reports we might see would come from web developers, who miss this ability to nag users. -Darin ___ 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
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. How far would you be willing to go in forcefully improving user experience? We could refuse to render dark backgrounds to make text more readable, for instance. - WBR, Alexey Proskuryakov ___ 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 7:08 PM, 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. How far would you be willing to go in forcefully improving user experience? We could refuse to render dark backgrounds to make text more readable, for instance. A counter-example, of course, is popup blocking, which did exactly that, much to users' delight. Adam ___ 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] The case for disallowing alerts in unload, redux
On 6/26/11 12:10 PM, Adam Barth aba...@webkit.org wrote: 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? One example of a useful confirm (I think) is a web-based irc client like irc.w3.org. It warns that you will close all active IRC connections, and lets you decide whether to stay on the page or navigate away. Alan ___ 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 8:12 PM, Alan Stearns stea...@adobe.com wrote: One example of a useful confirm (I think) is a web-based irc client like irc.w3.org. It warns that you will close all active IRC connections, and lets you decide whether to stay on the page or navigate away. But that can be done by retuning string in beforeunload, right? - Ryosuke ___ 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 8:12 PM, Alan Stearns stea...@adobe.com wrote: On 6/26/11 12:10 PM, Adam Barth aba...@webkit.org wrote: 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? One example of a useful confirm (I think) is a web-based irc client like irc.w3.org. It warns that you will close all active IRC connections, and lets you decide whether to stay on the page or navigate away. That's a beforeunload handler, which everyone agrees is useful. We're discussing alert() dialogs during the unload event. Adam ___ 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 8:17 PM, Adam Barth aba...@webkit.org wrote: On Sun, Jun 26, 2011 at 8:12 PM, Alan Stearns stea...@adobe.com wrote: On 6/26/11 12:10 PM, Adam Barth aba...@webkit.org wrote: 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? One example of a useful confirm (I think) is a web-based irc client like irc.w3.org. It warns that you will close all active IRC connections, and lets you decide whether to stay on the page or navigate away. That's a beforeunload handler, which everyone agrees is useful. We're discussing alert() dialogs during the unload event. 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. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
