Re: [webkit-dev] Timing updates for SVG SMIL animations
Am 27.07.2011 um 23:03 schrieb Darin Fisher: > Perhaps related to this thread, shouldn't we be basing SVG animations off of > the same animation scheduler that drives requestAnimationFrame and soon CSS > animations (https://bugs.webkit.org/show_bug.cgi?id=64591)? It seems less > than ideal to use a Timer. I'd love to share as much animation timing stuff as possible! Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Short commit-queue and EWS outage
Amazon is performing some maintenance on the "feeder" machine that vends jobs to the EWS and commit queue bots. Supposedly the system will be down for an hour from 1am PST to 2am PST tomorrow (in a couple hours). Hopefully nothing will explode. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing updates for SVG SMIL animations
Perhaps related to this thread, shouldn't we be basing SVG animations off of the same animation scheduler that drives requestAnimationFrame and soon CSS animations (https://bugs.webkit.org/show_bug.cgi?id=64591)? It seems less than ideal to use a Timer. -Darin On Wed, Jul 27, 2011 at 11:14 AM, Scott Graham wrote: > Hi, > > When the Timer is fired for SMILTimeContainer to update animations, the > elapsed time is calculated based on the client's currentTime(). > > That elapsed time is passed into updateAnimations and is used most of the > way "down". > > In some cases during the update though, SMILTimeContainer::elapsed() is > re-called (e.g. in SVGSMILElement::beginListChanged, endListChanged, > createInstanceTimesFromSyncbase). > > This seems somewhat incorrect because it means that various parts of the > animation will be updated with (slightly) different elapsed times than > others. It also makes it impractical to use a debugger to step the code. > > Does anyone disagree that all updates should use the same elapsed time > during the update? Or, in other words, is there any reason to re-get the > current wallclock time during the update? > > Thanks, > Scott > > > ___ > 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] Timing updates for SVG SMIL animations
On Wed, Jul 27, 2011 at 12:15 PM, Simon Fraser wrote: > On Jul 27, 2011, at 11:14 AM, Scott Graham wrote: > > Does anyone disagree that all updates should use the same elapsed time > during the update? Or, in other words, is there any reason to re-get the > current wallclock time during the update? > > I think your analysis is correct. You should file a bug for this in > bugs.webkit.org, and folks can review your proposed changes there. > > Thanks, done: https://bugs.webkit.org/show_bug.cgi?id=65274 scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing updates for SVG SMIL animations
On Jul 27, 2011, at 11:14 AM, Scott Graham wrote: > Hi, > > When the Timer is fired for SMILTimeContainer to update animations, the > elapsed time is calculated based on the client's currentTime(). > > That elapsed time is passed into updateAnimations and is used most of the way > "down". > > In some cases during the update though, SMILTimeContainer::elapsed() is > re-called (e.g. in SVGSMILElement::beginListChanged, endListChanged, > createInstanceTimesFromSyncbase). > > This seems somewhat incorrect because it means that various parts of the > animation will be updated with (slightly) different elapsed times than > others. It also makes it impractical to use a debugger to step the code. > > Does anyone disagree that all updates should use the same elapsed time during > the update? Or, in other words, is there any reason to re-get the current > wallclock time during the update? I think your analysis is correct. You should file a bug for this in bugs.webkit.org, and folks can review your proposed changes there. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Timing updates for SVG SMIL animations
Hi, When the Timer is fired for SMILTimeContainer to update animations, the elapsed time is calculated based on the client's currentTime(). That elapsed time is passed into updateAnimations and is used most of the way "down". In some cases during the update though, SMILTimeContainer::elapsed() is re-called (e.g. in SVGSMILElement::beginListChanged, endListChanged, createInstanceTimesFromSyncbase). This seems somewhat incorrect because it means that various parts of the animation will be updated with (slightly) different elapsed times than others. It also makes it impractical to use a debugger to step the code. Does anyone disagree that all updates should use the same elapsed time during the update? Or, in other words, is there any reason to re-get the current wallclock time during the update? Thanks, Scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Re: [New DOM property] selectionDirection on HTMLInputElement and HTMLTextAreaElement
-- Forwarded message -- From: "Ryosuke Niwa" Date: Jul 27, 2011 10:32 AM Subject: Re: [New DOM property] selectionDirection on HTMLInputElement and HTMLTextAreaElement To: "Ryosuke Niwa" Cc: "Aryeh Gregor" , "WebKit Development" < webkit-dev@lists.webkit.org>, "Tim Down" , "Ian Hixie" < i...@hixie.ch>, "Ojan Vafai" Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=674558 - Ryosuke On Jul 14, 2011 5:46 PM, "Ryosuke Niwa" wrote: > Hi all, > > I have a patch to add selectionDirection property on HTMLInputElement and > HTMLTextAreaElement on https://bugs.webkit.org/show_bug.cgi?id=60403. > > The purpose of this property is to let websites control base and extent of > selection. The property has been added to the HTML5 spec section > 4.10.20< http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection >, > and an extensive discussion about this > feature< http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029814.html > > has > been done on whatwg. Given the discussion took place on whatwg and how > simple this API is, I consider it to be a stable API. > > Best, > Ryosuke Niwa > Software Engineer > Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: > Hi webkit-dev, > > As some of you are probably aware, Mozilla is experimenting with > exposing some basic cryptographic primitives to web applications: > > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > > I wanted to get a sense from the WebKit community about how interested > we are in implementing this feature. My sense is that this API is > fairly early in it's lifecycle, so one perspective is that we should > wait for Mozilla to experiment for a bit longer and revisit this > question once the design is further along (e.g., submitted to the W3C > standards process). > > Another perspective is that there are some simple parts of the API > that we should implement now, and we can grow into the more involved > parts of the API as they mature. For example, the CryptoHash > interface can be implemented independently of the rest of the API and > provides value by itself. > > Thoughts? > > Adam > ___ > 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] Heads up : Qt port and its multimedia support.
Hello, Just a small heads up on the multimedia support for the Qt port. At the last webkit summit I've heard some Google folks a bit confused about our multimedia story and I'm sure others are so here is the story : We had a first Phonon backend, abandoned and really far from feature completion and far from working well : I removed it with http://trac.webkit.org/changeset/89832 as we thought it was not good idea to let it broken on the trunk. Then we have a QtMultimedia media player (Qt Multimedia is a separate add-on for Qt) that was added to the tree last year to provide a more extensive API than Phonon and supporting more platforms (Symbian). Unfortunately Qt Multimedia lacks of stability, the quality of the backends is really heterogenous and they behaves differently. I felt the support was built on unstable foundations so I decided it was not good option either. As a fun project, QtWebKit people decided to give a try on how the Qt port could use the GStreamer backend of webkit maintained by our GTK friends. Main changesets related : http://trac.webkit.org/changeset/72184, http://trac.webkit.org/changeset/83078. I also did the same on Mac, and it is possible for the Qt port to the QtKit media player maintained by Apple. Main changesets http://trac.webkit.org/changeset/87312 and http://trac.webkit.org/changeset/89617. Both implementation work pretty well with Qt, supports more features than we had with QtMultimedia, have better results in LayoutTests and make us work closer to the other webkit devs -> only benefits :D therefore after http://trac.webkit.org/changeset/91752 the GStreamer media player is the default on Linux and QtKit the default media player on Mac for the Qt port. On Windows and Symbian we still use QtMultimedia media player for now. Our Linux implementation is already covered by a bot so now the fellow GStreamer media player contributors should watch the Qt bots when they work on the media player. Unfortunately for our Apple friends we don't have yet a Qt Mac bot, though we are working on making one ready for build.webkit.org (we do have one running but not yet at the level to be promoted to build.webkit.org) so I will watch carefully the stuff going on the QtKit media player. Anyway if you have any question on the multimedia support in Qt and if you are unsure about a change that could affect QtWebKit in either GStreamer and QtKit, CC me on a bug or reach me on IRC. Thanks to Eric Carlson, Philippe Normand and others who helped me to make all of this working. Any questions? -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
These sorts of questions are probably better discussed on the whatwg mailing list (where there is currently a thread about DOMCrypt) because they're general questions about the use cases and features set of the API and not about WebKit's implementation (or non-implementation) of the API. Thanks for you interest. Adam On Wed, Jul 27, 2011 at 2:29 AM, Christoph Martens wrote: > > Well, I think that makes sense... But not for me. I have the opinion that > cloud-hosted keys aren't keys anymore - right? > I mean, man-in-the-middle attacks are the 100% use case when it comes to > encryption due to buggy DNS-protocol that can't be updated. > > I also think that this is kinda interesting when it comes to signing > uploads or files from inside a WebApp. > It makes sense to build a JavaScript API for hashing the values - so that > you can transfer data via unencrypted connection - which isn't smart, but > it should gain a low level of security depending on the algorithm. > But I wouldn't trust the hoster if there are plaintext passwords stored on > their servers. That's kinda php4 =/ > > Do you know which algorithms are planned to be implemented? Are there > twofish, blowfish or similar going to be included as well? > > __ > Christoph Martens > JavaScript Engineer, Zynga Germany > Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker > > > > Zynga Game Germany GmbH > An der Welle 4 > 60322 Frankfurt, Germany > cmart...@zynga.com > > > > > On 7/27/11 10:11 AM, "Adam Barth" wrote: > >>My sense is that the Mozilla folks want to start with the simple >>building blocks first and then work up to more complicated things like >>interacting with OS key stores and smart card readers. >> >>DOMCrypt is also useful for protecting data at rest, which isn't >>something you can do with TLS. For example, imagine that a web site >>wants to store a bunch of sensitive data on the client. The site can >>encrypt the data using DOMCrypt and then keep the KeyID off-device >>(e.g., in the cloud or in escrow). Later, the site can reunite the >>KeyID with the encrypted data on the client in order to decrypt. >> >>As a more concrete example of the above, consider a service like >>LastPass that wants to store your passwords (encrypted) on the client >>and never wants to touch your plaintext passwords on the server. >> >>These use cases all involve the public key encryption/decryption >>functionality. The hashing and MACing operations are somewhat lower >>level building blocks, but they seem like an easier place to start. >> >>Adam >> >> >>On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens >>wrote: >>> Hey Adam, >>> >>> I thought it might make sense to let the user specify a private key file >>> (e.g. an RSA-key) that is in the browsers KeyChain. >>> Would that make sense to have it implemented in the DOMCryptAPI? >>> >>> Otherwise I can't see many use cases, because I think encryption on a >>>high >>> OSI layer just doesn't make sense for me. >>> If someone is able to sniff SSL/TLS encrypted packages due to nulling he >>> will also be able to collect enough generated data to see how the >>>hashing >>> on the Browser-side works and which one will be the next hash generated >>>- >>> thanks to cuda and ati stream. >>> But that's just my personal opinion on that. >>> >>> Greets from Germany, >>> Chris >>> >>> __ >>> Christoph Martens >>> JavaScript Engineer, Zynga Germany >>> Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker >>> >>> >>> >>> Zynga Game Germany GmbH >>> An der Welle 4 >>> 60322 Frankfurt, Germany >>> cmart...@zynga.com >>> >>> >>> >>> >>> On 7/27/11 7:53 AM, "Adam Barth" wrote: >>> Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ 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.we
Re: [webkit-dev] DOMCrypt
Well, I think that makes sense... But not for me. I have the opinion that cloud-hosted keys aren't keys anymore - right? I mean, man-in-the-middle attacks are the 100% use case when it comes to encryption due to buggy DNS-protocol that can't be updated. I also think that this is kinda interesting when it comes to signing uploads or files from inside a WebApp. It makes sense to build a JavaScript API for hashing the values - so that you can transfer data via unencrypted connection - which isn't smart, but it should gain a low level of security depending on the algorithm. But I wouldn't trust the hoster if there are plaintext passwords stored on their servers. That's kinda php4 =/ Do you know which algorithms are planned to be implemented? Are there twofish, blowfish or similar going to be included as well? __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 10:11 AM, "Adam Barth" wrote: >My sense is that the Mozilla folks want to start with the simple >building blocks first and then work up to more complicated things like >interacting with OS key stores and smart card readers. > >DOMCrypt is also useful for protecting data at rest, which isn't >something you can do with TLS. For example, imagine that a web site >wants to store a bunch of sensitive data on the client. The site can >encrypt the data using DOMCrypt and then keep the KeyID off-device >(e.g., in the cloud or in escrow). Later, the site can reunite the >KeyID with the encrypted data on the client in order to decrypt. > >As a more concrete example of the above, consider a service like >LastPass that wants to store your passwords (encrypted) on the client >and never wants to touch your plaintext passwords on the server. > >These use cases all involve the public key encryption/decryption >functionality. The hashing and MACing operations are somewhat lower >level building blocks, but they seem like an easier place to start. > >Adam > > >On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens >wrote: >> Hey Adam, >> >> I thought it might make sense to let the user specify a private key file >> (e.g. an RSA-key) that is in the browsers KeyChain. >> Would that make sense to have it implemented in the DOMCryptAPI? >> >> Otherwise I can't see many use cases, because I think encryption on a >>high >> OSI layer just doesn't make sense for me. >> If someone is able to sniff SSL/TLS encrypted packages due to nulling he >> will also be able to collect enough generated data to see how the >>hashing >> on the Browser-side works and which one will be the next hash generated >>- >> thanks to cuda and ati stream. >> But that's just my personal opinion on that. >> >> Greets from Germany, >> Chris >> >> __ >> Christoph Martens >> JavaScript Engineer, Zynga Germany >> Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker >> >> >> >> Zynga Game Germany GmbH >> An der Welle 4 >> 60322 Frankfurt, Germany >> cmart...@zynga.com >> >> >> >> >> On 7/27/11 7:53 AM, "Adam Barth" wrote: >> >>>Hi webkit-dev, >>> >>>As some of you are probably aware, Mozilla is experimenting with >>>exposing some basic cryptographic primitives to web applications: >>> >>>https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >>> >>>I wanted to get a sense from the WebKit community about how interested >>>we are in implementing this feature. My sense is that this API is >>>fairly early in it's lifecycle, so one perspective is that we should >>>wait for Mozilla to experiment for a bit longer and revisit this >>>question once the design is further along (e.g., submitted to the W3C >>>standards process). >>> >>>Another perspective is that there are some simple parts of the API >>>that we should implement now, and we can grow into the more involved >>>parts of the API as they mature. For example, the CryptoHash >>>interface can be implemented independently of the rest of the API and >>>provides value by itself. >>> >>>Thoughts? >>> >>>Adam >>>___ >>>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] DOMCrypt
My sense is that the Mozilla folks want to start with the simple building blocks first and then work up to more complicated things like interacting with OS key stores and smart card readers. DOMCrypt is also useful for protecting data at rest, which isn't something you can do with TLS. For example, imagine that a web site wants to store a bunch of sensitive data on the client. The site can encrypt the data using DOMCrypt and then keep the KeyID off-device (e.g., in the cloud or in escrow). Later, the site can reunite the KeyID with the encrypted data on the client in order to decrypt. As a more concrete example of the above, consider a service like LastPass that wants to store your passwords (encrypted) on the client and never wants to touch your plaintext passwords on the server. These use cases all involve the public key encryption/decryption functionality. The hashing and MACing operations are somewhat lower level building blocks, but they seem like an easier place to start. Adam On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens wrote: > Hey Adam, > > I thought it might make sense to let the user specify a private key file > (e.g. an RSA-key) that is in the browsers KeyChain. > Would that make sense to have it implemented in the DOMCryptAPI? > > Otherwise I can't see many use cases, because I think encryption on a high > OSI layer just doesn't make sense for me. > If someone is able to sniff SSL/TLS encrypted packages due to nulling he > will also be able to collect enough generated data to see how the hashing > on the Browser-side works and which one will be the next hash generated - > thanks to cuda and ati stream. > But that's just my personal opinion on that. > > Greets from Germany, > Chris > > __ > Christoph Martens > JavaScript Engineer, Zynga Germany > Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker > > > > Zynga Game Germany GmbH > An der Welle 4 > 60322 Frankfurt, Germany > cmart...@zynga.com > > > > > On 7/27/11 7:53 AM, "Adam Barth" wrote: > >>Hi webkit-dev, >> >>As some of you are probably aware, Mozilla is experimenting with >>exposing some basic cryptographic primitives to web applications: >> >>https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >> >>I wanted to get a sense from the WebKit community about how interested >>we are in implementing this feature. My sense is that this API is >>fairly early in it's lifecycle, so one perspective is that we should >>wait for Mozilla to experiment for a bit longer and revisit this >>question once the design is further along (e.g., submitted to the W3C >>standards process). >> >>Another perspective is that there are some simple parts of the API >>that we should implement now, and we can grow into the more involved >>parts of the API as they mature. For example, the CryptoHash >>interface can be implemented independently of the rest of the API and >>provides value by itself. >> >>Thoughts? >> >>Adam >>___ >>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] DOMCrypt
Hey Adam, I thought it might make sense to let the user specify a private key file (e.g. an RSA-key) that is in the browsers KeyChain. Would that make sense to have it implemented in the DOMCryptAPI? Otherwise I can't see many use cases, because I think encryption on a high OSI layer just doesn't make sense for me. If someone is able to sniff SSL/TLS encrypted packages due to nulling he will also be able to collect enough generated data to see how the hashing on the Browser-side works and which one will be the next hash generated - thanks to cuda and ati stream. But that's just my personal opinion on that. Greets from Germany, Chris __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 7:53 AM, "Adam Barth" wrote: >Hi webkit-dev, > >As some of you are probably aware, Mozilla is experimenting with >exposing some basic cryptographic primitives to web applications: > >https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > >I wanted to get a sense from the WebKit community about how interested >we are in implementing this feature. My sense is that this API is >fairly early in it's lifecycle, so one perspective is that we should >wait for Mozilla to experiment for a bit longer and revisit this >question once the design is further along (e.g., submitted to the W3C >standards process). > >Another perspective is that there are some simple parts of the API >that we should implement now, and we can grow into the more involved >parts of the API as they mature. For example, the CryptoHash >interface can be implemented independently of the rest of the API and >provides value by itself. > >Thoughts? > >Adam >___ >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
