Re: [webkit-dev] Adding CSS3 background-position offsets.
On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote: Why does this feature have a flag at all? background-position with up to 4 arguments is specified with CSS3 background and borders. There are three major implementations with this feature. So we are just catching up. If the future works as expected (and we should have tests that verify it), then we should remove the flag completely. Sounds like good practice to me. Why _not_ start that feature with a flag then remove the flag when fully ready/tested??? Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. The computed style is there see http://trac.webkit.org/changeset/136378. I split the whole thing into two pieces to ease the review process. Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
On 11/30/12 23:59 , Hajime Morrita wrote: It looks github supports mirroring by pulling a repo from official location. http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror Ah, didn't know they provided that service, nice. I'm a bit worried about the sync delay though, as you say. Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
The premise of the specification is that using mouse event and touch events interchangeably is needed. In reality, nobody was really asking for that because it is a terrible idea. You can already easily unify pen, touch and mouse by writing very little JavaScript, but it is only useful in very few cases. It's not accurate to say nobody is asking for it. I agree that you generally need to design explicitly for touch and mouse interactions, and it's a legitimate concern that having a unified model may encourage developers to ignore important differences. However, developers are already attempting to unify the events today when the right design involves treating single-finger touch actions the same as mouse actions. For example, Google maps transforms both touch events and mouse events to a common unified event system, as does the PlayN game engine ( http://code.google.com/p/playn/). There has been at least SOME positive response in the web developer community to the idea of a unified event model, so I don't think it's fair to dismiss this idea as having no value out of hand. You can already easily unify pen, touch and mouse by writing very little JavaScript, but it is only useful in very few cases. It's not true that you can correctly unify the two with very little JavaScript. In particular, it's a subtle but significant difference that touch events are always delivered to the node that was first touched, while mouse events are delivered to whatever node the mouse cursor is currently over. The similar-but-different model is dangerously deceptive. For example, I recently came across an issue with a scrollable list library where occasionally touch scrolling would just stop working. We eventually realized that the library would sometimes remove nodes that had scrolled outside the visible region. So when it removes a node which just happened to be the one under the finger when scrolling started, all the touchmove events were no longer being delivered to the container (with not even a touchcancel). Removing nodes while their container is being manipulated is perfectly reasonable for the mouse model, but is subtly difficult with touch events. The only libraries I've seen that try to unify the targetting behavior of mouse and touch events are doing it by emulating pointer events eg. https://github.com/toolkitchen/PointerEvents. In particular, having apps state clearly and declaratively [3] whether a touch that starts on an element should result in browser behavior like scrolling or events which can be handled from JavaScript is potentially a big win for touch scrolling performance (something we struggle with in Chrome). This is a straw man. Chromium has implementation issues there, adding a new spec is not the solution to your problems. Having touch-action == auto, the default, will have the exact same issues as you have today. Having touch-action == none does not buy you much since it would have been implemented today by responding to the very first event. This is incorrect. Let me ellaborate on the benefit here. The fundamental difference between the two models is that touch events imply (although it's not well specified, and implementations differ) that it's possible to receive touchmove events while an element is being scrolled. In such a case, we can't really do threaded scrolling (especially if calling preventDefault on the touchmove is supposed to stop scrolling at that point). This makes it incredibly easy for web developers to accidentally defeat fast scrolling optimizations (just by having a touchmove handler on an element which happens to contain a scrollable div). For example, http://store.apple.com/us has a touchmove handler on the document (for no apparent good reason that I can see), which means that (in the chrome desktop implementation at least), we're unable to do scrolling without blocking on the main webkit thread because the page might really be expecting to receive events for the touch. In rare scenarios (when an app needs to receive touchmove events for a parent element, but one if it's children is scrollable) threaded scrolling appears impossible without potentially breaking changes to the touchevent model. Pointer events, on the other hand, were designed from the start to avoid this issue. They require the developer to explicitly state whether they want scrolling OR events. The spec is explicit that you will NOT receive events when the browser is performing a default action like scrolling. So touch-action: auto means that once a scroll gesture is detected (even when the element itself isn't actually scrollable), you get a pointercancel event indicating that the page will no longer receive events for the touch. If the developer REALLY wants to get all the events, they have to explicitly state that they're disabling scrolling on the element with touch-action: none. IMHO, it's far better to require developers to make an explicit trade-off
Re: [webkit-dev] pointer events specification - first editors draft
On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers rby...@chromium.org wrote: The premise of the specification is that using mouse event and touch events interchangeably is needed. In reality, nobody was really asking for that because it is a terrible idea. You can already easily unify pen, touch and mouse by writing very little JavaScript, but it is only useful in very few cases. It's not accurate to say nobody is asking for it. I agree that you generally need to design explicitly for touch and mouse interactions, and it's a legitimate concern that having a unified model may encourage developers to ignore important differences. However, developers are already attempting to unify the events today when the right design involves treating single-finger touch actions the same as mouse actions. For example, Google maps transforms both touch events and mouse events to a common unified event system, as does the PlayN game engine ( http://code.google.com/p/playn/). There has been at least SOME positive response in the web developer community to the idea of a unified event model, so I don't think it's fair to dismiss this idea as having no value out of hand. That is just reiterating my point. The fact is applications have already easily unified touch and mouse for the rare cases where it is needed. In particular, having apps state clearly and declaratively [3] whether a touch that starts on an element should result in browser behavior like scrolling or events which can be handled from JavaScript is potentially a big win for touch scrolling performance (something we struggle with in Chrome). This is a straw man. Chromium has implementation issues there, adding a new spec is not the solution to your problems. Having touch-action == auto, the default, will have the exact same issues as you have today. Having touch-action == none does not buy you much since it would have been implemented today by responding to the very first event. This is incorrect. Let me ellaborate on the benefit here. The fundamental difference between the two models is that touch events imply (although it's not well specified, and implementations differ) that it's possible to receive touchmove events while an element is being scrolled. In such a case, we can't really do threaded scrolling (especially if calling preventDefault on the touchmove is supposed to stop scrolling at that point). This makes it incredibly easy for web developers to accidentally defeat fast scrolling optimizations (just by having a touchmove handler on an element which happens to contain a scrollable div). For example, http://store.apple.com/us has a touchmove handler on the document (for no apparent good reason that I can see), which means that (in the chrome desktop implementation at least), we're unable to do scrolling without blocking on the main webkit thread because the page might really be expecting to receive events for the touch. In rare scenarios (when an app needs to receive touchmove events for a parent element, but one if it's children is scrollable) threaded scrolling appears impossible without potentially breaking changes to the touchevent model. Pointer events, on the other hand, were designed from the start to avoid this issue. They require the developer to explicitly state whether they want scrolling OR events. The spec is explicit that you will NOT receive events when the browser is performing a default action like scrolling. So touch-action: auto means that once a scroll gesture is detected (even when the element itself isn't actually scrollable), you get a pointercancel event indicating that the page will no longer receive events for the touch. If the developer REALLY wants to get all the events, they have to explicitly state that they're disabling scrolling on the element with touch-action: none. IMHO, it's far better to require developers to make an explicit trade-off between scrolling and app-level events, than it is to let them believe they can have it both ways without appreciating the performance implications. I question whether a modern touch API should even give developers the option of having janky scrolling, nevermind whether it should be so easy to opt-in to that mode accidentally. Tell me where it is said touch events have to works like you described. Multiple implementations, running on phones, have very efficient scrolling despite having handling for touch events. I am amazed you made an argument out of this. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiprocess networking in WebKit
On Tuesday 04 December 2012, Adam Barth wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD 4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. I like your ideas, but at least the two first points are in my mind operating system tasks, and already handled by some WebKit backends, so I hope it will be possible to put this logic at as high level as possible making it easier to ignore where it is unnecessary. I am considering it operating system tasks, because the benefits WebCore processes has in sharing connections or cache is the same all applications on a platform would have in doing the same. About the network process, I would just like to suggest not limiting it to one, not even to begin with. There is not much simplicity or efficiency to be gained by keeping all network request in the same process, and extra processes could be used for faster responses and increased security. Regards `Allan Sandfeld ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] commit-queue offline for the rest of the day
There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
On Tue, Dec 4, 2012 at 12:39 PM, Eric Seidel esei...@google.com wrote: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
On Tue, Dec 4, 2012 at 2:28 PM, Benjamin Poulain benja...@webkit.org wrote: On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers rby...@chromium.org wrote: The premise of the specification is that using mouse event and touch events interchangeably is needed. In reality, nobody was really asking for that because it is a terrible idea. You can already easily unify pen, touch and mouse by writing very little JavaScript, but it is only useful in very few cases. It's not accurate to say nobody is asking for it. I agree that you generally need to design explicitly for touch and mouse interactions, and it's a legitimate concern that having a unified model may encourage developers to ignore important differences. However, developers are already attempting to unify the events today when the right design involves treating single-finger touch actions the same as mouse actions. For example, Google maps transforms both touch events and mouse events to a common unified event system, as does the PlayN game engine (http://code.google.com/p/playn/). There has been at least SOME positive response in the web developer community to the idea of a unified event model, so I don't think it's fair to dismiss this idea as having no value out of hand. That is just reiterating my point. The fact is applications have already easily unified touch and mouse for the rare cases where it is needed. In particular, having apps state clearly and declaratively [3] whether a touch that starts on an element should result in browser behavior like scrolling or events which can be handled from JavaScript is potentially a big win for touch scrolling performance (something we struggle with in Chrome). This is a straw man. Chromium has implementation issues there, adding a new spec is not the solution to your problems. Having touch-action == auto, the default, will have the exact same issues as you have today. Having touch-action == none does not buy you much since it would have been implemented today by responding to the very first event. This is incorrect. Let me ellaborate on the benefit here. The fundamental difference between the two models is that touch events imply (although it's not well specified, and implementations differ) that it's possible to receive touchmove events while an element is being scrolled. In such a case, we can't really do threaded scrolling (especially if calling preventDefault on the touchmove is supposed to stop scrolling at that point). This makes it incredibly easy for web developers to accidentally defeat fast scrolling optimizations (just by having a touchmove handler on an element which happens to contain a scrollable div). For example, http://store.apple.com/us has a touchmove handler on the document (for no apparent good reason that I can see), which means that (in the chrome desktop implementation at least), we're unable to do scrolling without blocking on the main webkit thread because the page might really be expecting to receive events for the touch. In rare scenarios (when an app needs to receive touchmove events for a parent element, but one if it's children is scrollable) threaded scrolling appears impossible without potentially breaking changes to the touchevent model. Pointer events, on the other hand, were designed from the start to avoid this issue. They require the developer to explicitly state whether they want scrolling OR events. The spec is explicit that you will NOT receive events when the browser is performing a default action like scrolling. So touch-action: auto means that once a scroll gesture is detected (even when the element itself isn't actually scrollable), you get a pointercancel event indicating that the page will no longer receive events for the touch. If the developer REALLY wants to get all the events, they have to explicitly state that they're disabling scrolling on the element with touch-action: none. IMHO, it's far better to require developers to make an explicit trade-off between scrolling and app-level events, than it is to let them believe they can have it both ways without appreciating the performance implications. I question whether a modern touch API should even give developers the option of having janky scrolling, nevermind whether it should be so easy to opt-in to that mode accidentally. Tell me where it is said touch events have to works like you described. Multiple implementations, running on phones, have very efficient scrolling despite having handling for touch events. I am amazed you made an argument out of this. Nowhere does it say touch events have to work this way, that's part of the point - much of the behavior of touch events is still undocumented and unspecified. If we're going to make the implementations better while exposing a consistent model to applications, we need to document this sort of thing somewhere. Here is a stupid sample app
Re: [webkit-dev] commit-queue offline for the rest of the day
Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unresolved external on ews-win even after the symbol added in WebKit2.def.in
Hi, In https://bugs.webkit.org/attachment.cgi?id=177534, I added the symbol into Source/WebKit2/WebKit2.def.in trying to resolve the unresolved external error of the previous patch ( https://bugs.webkit.org/attachment.cgi?id=177506), but the error still occurred. I have read https://trac.webkit.org/wiki/ExportingSymbols (the WebKit2.def part should be updated). The only file I haven't changed is WebKit2.order (which I guess doesn't matter). Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.in is changed in the patch? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
Both the commit hashes mentioned in the log appear to be real hashes from today, about ten revisions apart. I'm not enough of a git expert to understand what's going on. Adam On Tue, Dec 4, 2012 at 2:49 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unresolved external on ews-win even after the symbol added in WebKit2.def.in
On Tue, Dec 4, 2012 at 3:00 PM, Xianzhu Wang wangxian...@chromium.orgwrote: Hi, In https://bugs.webkit.org/attachment.cgi?id=177534, I added the symbol into Source/WebKit2/WebKit2.def.in trying to resolve the unresolved external error of the previous patch ( https://bugs.webkit.org/attachment.cgi?id=177506), but the error still occurred. I have read https://trac.webkit.org/wiki/ExportingSymbols (the WebKit2.def part should be updated). The only file I haven't changed is WebKit2.order (which I guess doesn't matter). Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.in is changed in the patch? Sorry, the question should be: Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.inhttp://webkit2.def.in/ is changed in the *build log*? I guess the build system is not updating WebKit2.def from a changed WebKit2.def.in, or I did sth wrong adding the symbol. Can anyone verify it? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unresolved external on ews-win even after the symbol added in WebKit2.def.in
On Tue, Dec 4, 2012 at 4:09 PM, Xianzhu Wang wangxian...@chromium.orgwrote: On Tue, Dec 4, 2012 at 3:00 PM, Xianzhu Wang wangxian...@chromium.orgwrote: Hi, In https://bugs.webkit.org/attachment.cgi?id=177534, I added the symbol into Source/WebKit2/WebKit2.def.in trying to resolve the unresolved external error of the previous patch ( https://bugs.webkit.org/attachment.cgi?id=177506), but the error still occurred. I have read https://trac.webkit.org/wiki/ExportingSymbols (the WebKit2.def part should be updated). The only file I haven't changed is WebKit2.order (which I guess doesn't matter). Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.in is changed in the patch? Sorry, the question should be: Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.inhttp://webkit2.def.in/ is changed in the *build log*? Hit 'Send' too early. Please ignore the above sentence. I guess the build system is not updating WebKit2.def from a changed WebKit2.def.in, or I did sth wrong adding the symbol. Can anyone verify it? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unresolved external on ews-win even after the symbol added in WebKit2.def.in
Hi, I just tested with a temporary patch that removed most of the contents of WebKit2.def.in (https://bugs.webkit.org/attachment.cgi?id=177603). ews-win still reported one unresolved external just as for the previous patches ( http://queues.webkit.org/results/15153238). So I suspect that WebKit2.def was not updated from the changed WebKit2.def.in (I think otherwise there should be many other unresolved external errors). However I don't know much of Windows build and might be incorrect. @bfulgham, could you confirm? Thanks, Xianzhu On Tue, Dec 4, 2012 at 3:00 PM, Xianzhu Wang wangxian...@chromium.orgwrote: Hi, In https://bugs.webkit.org/attachment.cgi?id=177534, I added the symbol into Source/WebKit2/WebKit2.def.in trying to resolve the unresolved external error of the previous patch ( https://bugs.webkit.org/attachment.cgi?id=177506), but the error still occurred. I have read https://trac.webkit.org/wiki/ExportingSymbols (the WebKit2.def part should be updated). The only file I haven't changed is WebKit2.order (which I guess doesn't matter). Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.in is changed in the patch? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
