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] Adding ENABLE_CONTACTS to WebCore
On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Seconded. On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Windows Drawing Change (WebNodeHighlight) Logic
On Jun 27, 2011, at 1:55 AM, Simon Fraser wrote: This should go into a bug. Agreed. On Jun 26, 2011, at 4:12 PM, Brent Fulgham wrote: While investigating a separate issue, I noticed that I was hitting an assertion in the Cairo drawing layer because it was attempting to use an invalid HBITMAP created in the WebNodeHighlight::update method. The underlying issue was that the CreateDIBSection function was failing, because it was being requested to create a section of zero height. I think the following change would be safe for the CoreGraphics and Cairo ports, but wanted to see if anyone knew of a reason why it would be bad to exit early in the case of a zero height (or zero width) paint region. $ svn diff Index: win/WebNodeHighlight.cpp === --- win/WebNodeHighlight.cpp(revision 89759) +++ win/WebNodeHighlight.cpp(working copy) @@ -145,10 +145,14 @@ size.cx = webViewRect.right - webViewRect.left; size.cy = webViewRect.bottom - webViewRect.top; +if (!size.cx || !size.cy) +return; + BitmapInfo bitmapInfo = BitmapInfo::createBottomUp(IntSize(size)); void* pixels = 0; OwnPtrHBITMAP hbmp = adoptPtr(::CreateDIBSection(hdc, bitmapInfo, DIB_RG B_COLORS, pixels, 0, 0)); +ASSERT_WITH_MESSAGE(hbmp.get(), ::CreateDIBSection failed with error %lu, ::GetLastError()); ::SelectObject(hdc, hbmp.get()); I don't see any reason why this would be bad. -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 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] Adding ENABLE_CONTACTS to WebCore
Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. Ojan On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.com wrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome , and send me your complaints! ___ 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] Proposed Windows Drawing Change (WebNodeHighlight) Logic
On Mon, Jun 27, 2011 at 5:36 AM, Adam Roben aro...@apple.com wrote: On Jun 27, 2011, at 1:55 AM, Simon Fraser wrote: This should go into a bug. Agreed. Opened https://bugs.webkit.org/show_bug.cgi?id=63484. Thanks, -Brent ___ 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] Switching to new-run-webkit-tests
Looking at the master bug, it looks like we're close to switching the project to new-run-webkit-tests: https://bugs.webkit.org/show_bug.cgi?id=34984 There appear to be 6 remaining blocking issues: https://bugs.webkit.org/showdependencytree.cgi?id=34984hide_resolved=1 We would like to hear from others who have tried new-run-webkit-tests, if they have issues which they believe should block migrating to NRWT. (If so, please file and block the master bug!) Thanks. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
On Tue, Jun 28, 2011 at 1:17 AM, Eric Seidel e...@webkit.org wrote: There appear to be 6 remaining blocking issues: https://bugs.webkit.org/showdependencytree.cgi?id=34984hide_resolved=1 We would like to hear from others who have tried new-run-webkit-tests, if they have issues which they believe should block migrating to NRWT. (If so, please file and block the master bug!) I can see the GTK+ port thing with Xvfb is there already, so not a lot to add. NWRT is more sensitive to slow tests than the old infrastructure, so we had to add a bunch of them to the expectations file; I don't think this is particularly bad. In any case with the Xvfb patch and my local expectations file things run beautifully and way faster than before, so looking great from our side! Xan Thanks. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Location of tests for new CSS features (regions and exclusions)
There are two patches in the works for regions and exclusions that include tests: https://bugs.webkit.org/show_bug.cgi?id=61726 https://bugs.webkit.org/show_bug.cgi?id=61730 The patches started with tests in these paths: LayoutTests/fast/regions LayoutTests/fast/exclusions But during the responses to feedback, the test path schemes have diverged. They are currently: LayoutTests/fast/css-regions LayoutTests/fast/css/exclusions I am assuming that neither of these current paths are correct, since there are no other examples using paths like them. But I do see CSS3 features in different places - transitions tests have their own folder, but selector tests are in a css3 folder. So I'm guessing that either we should (1) use the original paths: LayoutTests/fast/regions LayoutTests/fast/exclusions Or (2) move the folders into the css3 folder: LayoutTests/fast/css3/regions LayoutTests/fast/css3/exclusions Unless I hear an argument for (2) I'm planning on submitting test patches using (1). Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [Webkit GTK][Windows] Plug-ins fails to load
Hi, I have configured Webkit GTK port on Win32. Apart from that I have created some NPAPI architecture based plug-in to implement my own functionality. I have created DLL's and keeping them on the standard MOZ_PLUGIN_PATH path. But my GTKLauncher application is unable to load these plug-ins. What I am doing wrong? I couldn't find anything on net apart from a bug ( https://bugs.webkit.org/show_bug.cgi?id=54531 ). Could anybody please confirm whether it is possible to load plug-in on windows or not. Thanks, Dipak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
