Hi, I'm sorry that I did it yesterday.
Usually I use webkit-patch. But that patch had 2 bug URLs and
webkit-patch didn't work for it.
So I rewrote ChangeLogs - with the wrong way.
If "webkit-patch land" support --bug-id, it might be helpful for my case.
Thanks.
--
morita
On Tue, Aug 10, 2010 at 2
> As Ojan indicated,
> the use cases for DOM Mutation events are extremely limited and to me,
> most of them feel like we should be solving them differently anyway.
This is the question I'm most interested in.
You say the use cases are limited. How do you know? Are you speaking about when
you wo
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
> I am very, very tempted to just get rid of them. As Ojan indicated,
> the use cases for DOM Mutation events are extremely limited and to me,
> most of them feel like we should be solving them differently anyway.
>
> However, with the introducti
I am very, very tempted to just get rid of them. As Ojan indicated,
the use cases for DOM Mutation events are extremely limited and to me,
most of them feel like we should be solving them differently anyway.
However, with the introduction of extensions into Chromium and Safari,
DOM Mutation events
Hi Ojan.
> Mutation events are a huge source of crashes and they complicate WebCore code
> considerably.
Indeed. I also think mutation events unnecessarily complicate the API space
from a web content author's perspective.
> Also, I don't see any evidence that mutation events are used much othe
On Mon, Aug 9, 2010 at 4:39 PM, Ojan Vafai wrote:
> On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth wrote:
>
>> On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak wrote:
>> > If mutation events tend to break editing, one simple solution is to turn
>> then off within the scope of editing operations an
On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth wrote:
> On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak wrote:
> > If mutation events tend to break editing, one simple solution is to turn
> then off within the scope of editing operations and send a single mutation
> event at the end. It's not clea
On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak wrote:
> I think this carries an assumption that the right internal abstractions are
> necessarily also a sensible public API. I don't know if that is a good
> assumption.
>
You're right that I was making this assumption. My intuition is that the
There are other cases as well where you want a copy. Patterns are another
example. For example you can create a pattern from another canvas, and I don't
think it's supposed to be live if that other canvas later changes. There are
examples in SVG as well where patterns are used and I am pretty
I would be interested as well in seeing a blog post about this new feature.
Very cool stuff, good work!
Josh
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Mon, Aug 9, 2010 at 10:51 AM, Jian Li wrote:
> I noticed that several patches landed recently have the incorrect date put
> in the commit messages and ChangeLog. Please fix the incorrect information
> in ChangeLog. For the commit messages, anyone know if we can fix them or
> not?
> Please make
On Aug 9, 2010, at 12:48 PM, Pavel Feldman wrote:
> See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium
> nightly to the left +
> WebKit nightly to the right. WebKit nightly connects remotely to Chromium
> over HTTP on the port
> 9222 and does remote debugging including DO
Yes. The commit-queue uses svn-apply which knows how to fix the date using:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/VCSUtils.pm#L1231
-eric
On Mon, Aug 9, 2010 at 2:06 PM, Fady Samuel wrote:
> What about the case where between the time you submit the patch and it gets
> committ
What about the case where between the time you submit the patch and it gets
committed, a day passes by...does the commit queue fix this automatically,
or does someone have to go back and fix it manually?
Fady
On Mon, Aug 9, 2010 at 1:51 PM, Jian Li wrote:
> Hi,
>
> I noticed that several patche
Hi guys,
As some of you know, we are working on a remote debugging feature in Web
Inspector. There are many good reasons behind the project including the
following:
- Debugging WebKit on embedded devices
- Shaping up a good protocol for ourselves
- Introducing external SDKs on top of the protocol
On Mon, Aug 9, 2010 at 10:51 AM, Jian Li wrote:
> Please make sure the correct date is used when you land your patch manually.
This is one of my favorite features of webkit-patch, which seems to do the
right thing at least in the case of git.
Martin
__
Hi,
I noticed that several patches landed recently have the incorrect date put
in the commit messages and ChangeLog. Please fix the incorrect information
in ChangeLog. For the commit messages, anyone know if we can fix them or
not?
Please make sure the correct date is used when you land your patc
17 matches
Mail list logo
