[webkit-dev] Landing your own patches
Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How loading a frame ought to work
Strongly support your suggested refactoring -- on the condition that you clearly document it on the wiki as you go. This just gets more and more complex and I don't think we can risk more refactoring resulting in potentially even fewer people having a very clear idea of what is happening. Also I wonder why fragment scroll isn't covered by the policy callback. I haven't had a need to block that before but I can think of some cases right now where it might be handy. I'm not advocating bloat without a cause, but perhaps if you're refactoring it we might un-special-case it. On 2009-10-13, at 1:50 PM, Adam Barth wrote: I've been studying the various objects related to loading frames, and I wanted to get feedback on the below proposal before making a bunch of changes. There seem to be three main objects related to the loading state for a frame: * MainResourceLoader. MainResourceLoader inherits from ResourceLoader and receive callbacks from the network stack. It's primary task is to take callbacks from the network stack and route them to the appropriate higher-level APIs. Currently, MainResourceLoader is also concerned with navigation policies, but I'm not sure if that's correct. * DocumentLoader. DocumentLoader is responsible for all the document-specific loading state. For example, the DocumentLoader should know if we've received any data for this document yet and should be in charge of actually stuffing the received data into the Document. (Both of these examples are currently done by FrameLoader.) * FrameLoader. FrameLoader is responsible for the frame-level loading state. Essentially, the FrameLoader's job is to determine the disposition of load requests and shepherd DocumentLoaders through the policy / provisional / committed states. The FrameLoader goes through the following process: 1) Dispatch. A load request enters the machine. a) The request is routed to the appropriate frame. b) If the request should generate a fragment scroll, scroll the view and exit the machine. c) Otherwise, create a DocumentLoader to encapsulate the load state for this request. 2) Policy Check. Ask the FrameLoaderClient's policy interface whether the embedder actually wants to go through with the load and wait for a response. 3) Provisional. Once we get the go-ahead from the client, we actually start generating a network request (i.e., create MainResourceLoader). In this phase, we receive redirects and headers, and eventually decide whether to commit the load. 4) Committed. We've decided to actually navigate the frame. a) Detach the old document from the frame. b) Attach the new document to the frame. In addition to shifting a bunch of the document-specific loading state from FrameLoader to DocumentLoader, I think we should create two new objects: A) FrameNavigator. This object would handle the dispatching phase above. The goal of creating this object is to let FrameLoader focus on load requests that will actually result in network / cache traffic. B) LoadObserver. Currently ResourceLoader forwards many of the network stack callbacks (e.g., ResourceLoader::didReceiveResponse) to FrameLoader so they can be farmed out to the Web Inspector, ProgressTracker, FrameLoaderClient, and others. The goal of this object is to remove that complexity from FrameLoader. Let me know if you have any comments or suggestions. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How loading a frame ought to work
On Tue, Oct 13, 2009 at 3:00 PM, George Staikos stai...@kde.org wrote: Strongly support your suggested refactoring -- on the condition that you clearly document it on the wiki as you go. This just gets more and more complex and I don't think we can risk more refactoring resulting in potentially even fewer people having a very clear idea of what is happening. In general, the WebKit project seems to prefer easily understandable code to external documentation. When thing settle down some more, I'll certainly add comments explaining what the role of each object is. Also I wonder why fragment scroll isn't covered by the policy callback. I haven't had a need to block that before but I can think of some cases right now where it might be handy. I'm not advocating bloat without a cause, but perhaps if you're refactoring it we might un-special-case it. This seems like a feature we can add in the future should we find a need for it. Certainly nothing I'm doing will preclude that. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
Has this actually been a problem? I know the commit-queue broke something today when landing a patch for Evan Martin, but he was on IRC and I made sure he was on the hook to watch the bots before I had to leave. If I've landed things via commit-queue and not cleaned up after them, I certainly apologize. Eric has talked about having the commit-queue watch the bots and send out email to the appropriate people when the commit-queue breaks something. What I see as more of a problem is the failing tests on Tiger and SnowLeopard the past few days. Having red columns on the tree makes it harder to see when a new regression is introduced. Looking at the tree, the issue seems to have been resolved. If that was caused by the commit-queue, then I agree we should improve the commit-queue process. If it was caused by someone committing their own patch, then I think we should improve the self-commit process. Adam On Tue, Oct 13, 2009 at 11:22 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ 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
Re: [webkit-dev] Landing your own patches
On Wed, Oct 14, 2009 at 9:21 AM, Evan Martin e...@chromium.org wrote: I think the lesson I've learned with this change is that I shouldn't tackle hard bugs to get started in WebKit. I agree that it's a good idea to start small, the same way the Chromium project asks new contributors to start small. If I'd had commit access I would've been able to check in/out my patch immediately when I saw I broke the non-Mac platforms; as it was I begged someone to cq+ my r+'d patch, came back 20 minutes later to see that the commit bot flaked, begged someone to set it again, came back 30 minutes later to learn I'd broken the build, and then had to pawn off cleaning up the breakage on dglazkov since I couldn't revert it. :( Normally I would not have cq+'ed your patch and then disappeared. I did that because you seemed enthusiastic about getting your patch landed and, in the worse case, I figured Tony could help dig you out of whatever hole I put you in because his desk is right next to yours. It seems reasonable enough to me to require me and others start small. There's certainly no requirement to start small. It's more work to interact with the project without the commit bit, but it's certainly possible. I apologize for my noobness, but I've never been able to understand the webkit buildbots since a lot of them are red all the time. Is this documented anywhere? WebKit doesn't have the same green tree aesthetic as Chromium does. I think the main reason is because WebKit gets about half as many commits per hour as the main Chromium tree and the commits are more spread out over a 24hr period. Another reason is that the GTK and Qt ports have fewer maintainers than the Mac and Windows ports. If we were to close to tree whenever a bot went red (including the GTK and Qt ports), folks who were less interested in maintaining those ports would end up devoting more time to those ports. However, the project itself doesn't want to play favorites, so we don't want to have an official policy of close the tree for Mac and Windows redness. Over time, the WebKit tree has been getting greener. When I started working on the project, all the bots were red all the time. The current unofficial culture seems to be as follows: 1) Ensure your change does not introduce new test failures on Mac or Windows by comparing the list of failing tests before and after your change (mentally filtering out the flaky tests). 2) If GTK or QT is compiling before your change, make sure GTK and QT are compiling after your change. 3) If you notice someone disobeying rules (1) or (2), either ping them on IRC or send them email. One thing that's helped a lot on Chrome is to split the bots into if these break, revert your patch (the builders seen on http://build.chromium.org/ -- in theory the big box at the top should be all green), and then these bots are tracking stuff that we'd like to keep working (the builders seen on http://build.chromium.org/buildbot/waterfall.fyi/console). Or to use different colors (red = something has gone horribly wrong, orange = this is broken but maybe ok), for example tracking compile failure vs layout test fails. The problem with this approach here is that it is counter to the cultural norm of not playing favorites with the ports. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
On Wed, Oct 14, 2009 at 10:25 AM, David Hyatt hy...@apple.com wrote: On Oct 14, 2009, at 1:22 AM, Sam Weinig wrote: (most patches probably won't break a build, unless you are named Dave Hyatt). Unnecessary. Wow. T-shirts never lie http://www.cafepress.com/tinderbox.1417340 http://www.cafepress.com/tinderbox.1417340PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
On Wed, Oct 7, 2009 at 10:02 PM, Eric Seidel e...@webkit.org wrote: I had thought that we resolved ages ago that we would no longer be indenting code inside namespaces in header files, since that just results in the entire class declaration being pointlessly indented. I like this change (even though it's hard to make Emacs play along). Is there a way to get Emacs to auto-indent this correctly? :'( This (not indenting namespaces) is part of the Google C++ style. I am still an amateur emacs user, but it looks like c-offsets-alist with (innamespace . 0) is the setting you want. See: http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el As for how to actually set that in C++-mode, your help is welcome. :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth aba...@webkit.org wrote: Has this actually been a problem? I know the commit-queue broke something today when landing a patch for Evan Martin, but he was on IRC and I made sure he was on the hook to watch the bots before I had to leave. If I've landed things via commit-queue and not cleaned up after them, I certainly apologize. Eric has talked about having the commit-queue watch the bots and send out email to the appropriate people when the commit-queue breaks something. This is kinda derailing the thread, since Sam was just asking committers to not use the c-q bot, but since you brought it up... I think the lesson I've learned with this change is that I shouldn't tackle hard bugs to get started in WebKit. The patch that broke affected all platforms and touched how CSS values are presented to JS, so it was no surprise to me that it broke something. If I'd had commit access I would've been able to check in/out my patch immediately when I saw I broke the non-Mac platforms; as it was I begged someone to cq+ my r+'d patch, came back 20 minutes later to see that the commit bot flaked, begged someone to set it again, came back 30 minutes later to learn I'd broken the build, and then had to pawn off cleaning up the breakage on dglazkov since I couldn't revert it. :( It seems reasonable enough to me to require me and others start small. There are plenty of bugs I'd like to convert into tests. Yesterday I landed two cosmetic (widget rendering) changes that only affect Chrome and aren't even covered by any webkit.org builders. Though I worry that means that only people who have taken the time to become committers will ever be able to make large changes. (The alternative technical solution is to improve the c-q bot to test on all platforms, but that still leaves the revert problem.) What I see as more of a problem is the failing tests on Tiger and SnowLeopard the past few days. Having red columns on the tree makes it harder to see when a new regression is introduced. I apologize for my noobness, but I've never been able to understand the webkit buildbots since a lot of them are red all the time. Is this documented anywhere? If not, I volunteer to make the website mods to document this if anyone is willing to explain it to me on a casual level. From a glance at build.webkit.org it seems the leaks bot and the GTK bots will always be red (and the Qt one is borderline). One thing that's helped a lot on Chrome is to split the bots into if these break, revert your patch (the builders seen on http://build.chromium.org/ -- in theory the big box at the top should be all green), and then these bots are tracking stuff that we'd like to keep working (the builders seen on http://build.chromium.org/buildbot/waterfall.fyi/console). Or to use different colors (red = something has gone horribly wrong, orange = this is broken but maybe ok), for example tracking compile failure vs layout test fails. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
On Wed, Oct 14, 2009 at 9:56 AM, Adam Barth aba...@webkit.org wrote: WebKit doesn't have the same green tree aesthetic as Chromium does. I think the main reason is because WebKit gets about half as many commits per hour as the main Chromium tree and the commits are more spread out over a 24hr period. Another reason is that the GTK and Qt ports have fewer maintainers than the Mac and Windows ports. If we were to close to tree whenever a bot went red (including the GTK and Qt ports), folks who were less interested in maintaining those ports would end up devoting more time to those ports. However, the project itself doesn't want to play favorites, so we don't want to have an official policy of close the tree for Mac and Windows redness. I filed https://bugs.webkit.org/show_bug.cgi?id=30367 and posted a doc patch there. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
It seems like if you are a committer, you should still be able to use the commit queue, you just need to do it responsibly. If the problem is with people setting the bit and walking away, why not include a warning to the effect of: Setting commit-queue+ is equivalent to svn commit so it is understood that you should follow the same policies when setting the bit as you do when committing manually? For example, my workflow is as follows: 1. Check the status of the commit queue to make sure it isn't busy and is ready to accept my patch 2. Make sure I'm logged into #webkit 3. Set commit-queue+ 4. Wait ... watch for IRC notifier for my commit (simple notifier set up on my username) 1. If my commit doesn't go through and I need to leave my desk, set commit-queue- so it doesn't commit while I'm away. 5. Watch the tree and make sure there was no issues If anything, I'm being a better citizen because I'm running the tests on both Windows (locally) and Mac (commit-queue) before submitting. (Agreed that this is the wrong tool, try severs would be better, but in the absence of try servers, I don't see how I'm causing harm by using commit-queue). Julie On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth aba...@webkit.org wrote: Has this actually been a problem? I know the commit-queue broke something today when landing a patch for Evan Martin, but he was on IRC and I made sure he was on the hook to watch the bots before I had to leave. If I've landed things via commit-queue and not cleaned up after them, I certainly apologize. Eric has talked about having the commit-queue watch the bots and send out email to the appropriate people when the commit-queue breaks something. What I see as more of a problem is the failing tests on Tiger and SnowLeopard the past few days. Having red columns on the tree makes it harder to see when a new regression is introduced. Looking at the tree, the issue seems to have been resolved. If that was caused by the commit-queue, then I agree we should improve the commit-queue process. If it was caused by someone committing their own patch, then I think we should improve the self-commit process. Adam On Tue, Oct 13, 2009 at 11:22 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Landing your own patches
This only works when you set the commit-queue+ bit. Currently, the convention is that people without commit access set commit-queue? to signal that they'd like a reviewer to commit-queue+ it when they r+ it. Sometimes reviewers will go so far as to commit-queue+ it unless they see a commit-queue-. Since there's no way for someone to know when their patch is going to be reviewed, it seems like this may be what's broken about the system. Maybe reviewers should never commit-queue+ stuff. And non-committers should just ask on IRC for someone to commit-queue+ their patch when it's ready to land. J On Wed, Oct 14, 2009 at 2:10 PM, Julie Parent jparent+web...@gmail.comjparent%2bweb...@gmail.com wrote: It seems like if you are a committer, you should still be able to use the commit queue, you just need to do it responsibly. If the problem is with people setting the bit and walking away, why not include a warning to the effect of: Setting commit-queue+ is equivalent to svn commit so it is understood that you should follow the same policies when setting the bit as you do when committing manually? For example, my workflow is as follows: 1. Check the status of the commit queue to make sure it isn't busy and is ready to accept my patch 2. Make sure I'm logged into #webkit 3. Set commit-queue+ 4. Wait ... watch for IRC notifier for my commit (simple notifier set up on my username) 1. If my commit doesn't go through and I need to leave my desk, set commit-queue- so it doesn't commit while I'm away. 5. Watch the tree and make sure there was no issues If anything, I'm being a better citizen because I'm running the tests on both Windows (locally) and Mac (commit-queue) before submitting. (Agreed that this is the wrong tool, try severs would be better, but in the absence of try servers, I don't see how I'm causing harm by using commit-queue). Julie On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth aba...@webkit.org wrote: Has this actually been a problem? I know the commit-queue broke something today when landing a patch for Evan Martin, but he was on IRC and I made sure he was on the hook to watch the bots before I had to leave. If I've landed things via commit-queue and not cleaned up after them, I certainly apologize. Eric has talked about having the commit-queue watch the bots and send out email to the appropriate people when the commit-queue breaks something. What I see as more of a problem is the failing tests on Tiger and SnowLeopard the past few days. Having red columns on the tree makes it harder to see when a new regression is introduced. Looking at the tree, the issue seems to have been resolved. If that was caused by the commit-queue, then I agree we should improve the commit-queue process. If it was caused by someone committing their own patch, then I think we should improve the self-commit process. Adam On Tue, Oct 13, 2009 at 11:22 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ 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 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
Re: [webkit-dev] [chromium-dev] Learning Webkit: High Level Webkit overview?
On Wed, Oct 14, 2009 at 7:21 PM, Darin Adler da...@apple.com wrote: On Oct 14, 2009, at 3:33 AM, tali garsiel wrote: I'm also trying to figure out Webkit flow. I modified the Mozilla diagram to my understanding of Webkit flow. Is it correct? The diagram seems basically OK, although I don’t entirely understand what the boxes are. The boxes in a flow chart are supposed to be processing steps. From Wikipedia: Processing steps:Represented as rectangles. Examples: Add 1 to X; replace identified part; save changes or similar. May be the name should be CSS parsing instead of CSS Parser . The diagram leaves out the CSS object model, which is what the CSS parser actually produces. And you can edit it using the DOM API. The CSS style selector produces render style from the CSS object model objects, and the render style is closely related to the render tree and could even be considered part of it. Yes.I see now. The CSS parser products are CSSStyleSheets objects which contain CSS rule lists - right?. If I understand correctly the render style gets created in the process of creating the render tree. The flow is: Node::attach() Node::createRendererIfNeeded() CSSStyleSelector::styleForElement(...) I also see that the HTML Parser initiates the parsing of the CSS style sheets - this is not apparent from my diagram - is this correct?. I’m not sure I understand what it means to have a box labeled “layout” pointing to the render tree. It is true that layout is a procedure performed on the render tree. Layout box means a layout processing on the input. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Learning Webkit: High Level Webkit overview?
On Oct 14, 2009, at 2:44 PM, tali garsiel wrote: The CSS parser products are CSSStyleSheets objects which contain CSS rule lists - right?. Yes. If I understand correctly the render style gets created in the process of creating the render tree. The flow is: Node::attach() Node::createRendererIfNeeded() CSSStyleSelector::styleForElement(...) Yes. I also see that the HTML Parser initiates the parsing of the CSS style sheets - this is not apparent from my diagram - is this correct?. Not really. There are multiple ways to initiate parsing of CSS style sheets. I’m not sure the best way to reflect this in your diagram. Two of the most common ways: WebKit loads style sheets and parses them in response to the creation of a link element in an HTML document, and one of the ways to create an element is with the HTML parser. WebKit also parses style sheets in style elements, and in this case the parsing is triggered when the HTML parser calls finishParsingChildren on the style element. But I think it's possibly misleading to state that the HTML parser initiates the parsing of the style sheets, since it doesn’t do it directly, and it doesn’t do it for all style elements. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to achieve similar behavior as event.rangeParent and event.rangeOffset in FireFox.
I am using caretRangeFromPoint to convert mouse position to the character position within an element. I am trying to use it to achieve the same behavior as event.rangeParent and event.rangeOffset in FireFox. So I think it should return different results if hit test on a text node or the text node's parent element whose first child is the text node. But the behavior of Document.caretRangeFromPoint() is different. I attached a test case in this email. Following are the steps to show the difference: 1. open the attached page 2. mouse click right before the first word the in the list, the container node and offset in the range returned from caretRangeFromPoint() is the text node the first, and offset 0. 3. mouse click some where in the empty space around the bullet before the first. caretRangeFromPoint() returns the same as the above. By comparison, open the above page in Firefox and repeat the above steps, you will see the node (and offset) returned from event.rangeParent/rangeOffset in FireFox are different if click on the text node and the element node. Does webkit have anyway to tell the difference (hit test hits different type of nodes)? Seems that none of document.caretRangeFromPoint()'s containerNodes, event.target, and document.elementFromPoint() shows any difference in the above 2 clicks. Should I propose a new API for such differentiation? Thanks, Xiaomei Title: document.elementFromPoint() Method the first the second ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
To resurrect this thread. I'm looking in implementing some of the methods that we discussed so that web developers have no excuse in simulating sleeps in unload handlers. From this thread, the options that were discussed were -a ping: The pros were that it would work without JavaScript, and could be disabled easily via an option like referral headers. But given that it's not possible for this to work in iframes in Firefox and perhaps other browsers and that the users of the sleeps are ad networks using iframes, it doesn't fit the requirements. -window.sendPing(): elegant, but requires educating web developers. also required JavaScript to be enabled. -Image trick (image loads started from unload handlers outlive the page): simple, maintains comparability with IE and existing sites. however a little inelegant and requires JavaScript. -allow XHR with a special flag, or ones started from unload handlers to outlive the page: doesn't seem worth it since it involves both extra complexity in WebCore, requires changing web sites, and doesn't have compatibility with IE In an ideal world, I would prefer window.sendPing. Given the benefits of maintaining compatibility with IE and existing sites, I do think the image loading trick is the best solution at this point. I've gone back and forth on this a few times, but at the end the limitations of a ping where it does not work for iframes in other browsers render it useless. Although the image trick requires JavaScript, I think this is acceptable since the problem sites now already use JavaScript to simulate sleeps and fetch the image, so we're not placing more requirements on them. Do we have agreement on proceeding with implementing the Image based approach? Thanks, John On Thu, Sep 17, 2009 at 6:26 PM, John Abd-El-Malek j...@google.com wrote: On Thu, Sep 17, 2009 at 4:08 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 17, 2009, at 2:16 PM, John Abd-El-Malek wrote: I think the image trick is more attractive than a ping because it's easier for web developers to use. But I'm not convinced it's the cleanest method we can come up with. If we are expecting web developers to change, then I'd prefer something more explicit link asyncPing(url). The benefit is that it doesn't tie up connection limits like image loading would, and hence shouldn't impact the navigated page's loading. The UA is then free to pick the best time to do the ping, i.e. when network activity has died down. With the Image trick, web developers don't have to change, other than to get rid of the busy loop. I wouldn't be too averse to also adding an explicit ping API, but it seems to me it's possible to do many of the optimizations you describe for the Image-in-unload trick. Good points. These were my biggest sticking point with the image trick, now that I'm not concerned about them anymore, I really appreciate the compatibility with IE that this gives. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
On Oct 14, 2009, at 6:43 PM, John Abd-El-Malek wrote: To resurrect this thread. I'm looking in implementing some of the methods that we discussed so that web developers have no excuse in simulating sleeps in unload handlers. ... -Image trick (image loads started from unload handlers outlive the page): simple, maintains comparability with IE and existing sites. however a little inelegant and requires JavaScript. ... Do we have agreement on proceeding with implementing the Image based approach? Yes, I think we should let image loads from unload handlers run to completion. I don't see much downside, and the compatibility with IE behavior is pretty compelling. The other ideas you mentioned don't seem as good. Making a new API or a new XHR flag would be WebKit-specific and thus inferior to the Image thing. And I think a ping, though it may have its uses, does not apply to this use case. Dynamically creating an a element and sending it a fake click event is rather awkward. And navigations initiated from the unload handler do not actually happen. It would be weird to special-case things so that the ping is sent anyway, even though the navigation does not go through. Let's reserve a ping for hyperlink auditing and not bend it to the purpose of page close auditing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
