On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov <[email protected]> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
