On Mon, Aug 2, 2010 at 7:33 AM, Dan Bernstein m...@apple.com wrote:
On Aug 2, 2010, at 4:28 AM, Alexey Proskuryakov wrote:
29.07.2010, в
10:59, Darin Adler написал(а):
The directory should be eventually be
named Tests or WebKitTests or
RegressionTests.
Ideally,
the directory
Hi,
I'm currently looking into a bug (42799), and find that class
CSSComputedStyleDeclaration has a property 'RefPtrNode m_node', which
means this class takes ownership of the Node to which the computedStyle
object belongs back to. Does this mean that if the computedStyle object get
released, the
On Wed, Aug 4, 2010 at 4:05 PM, Yuxiang Luo lu...@google.com wrote:
Hi,
I'm currently looking into a bug (42799), and find that class
CSSComputedStyleDeclaration has a property 'RefPtrNode m_node', which
means this class takes ownership of the Node to which the computedStyle
object belongs
On Wed, Aug 4, 2010 at 4:05 PM, Yuxiang Luo lu...@google.com wrote:
Hi,
I'm currently looking into a bug (42799), and find that class
CSSComputedStyleDeclaration has a property 'RefPtrNode m_node', which
means this class takes ownership of the Node to which the computedStyle
object belongs
Good morning WebKit crowd,
I'd like to discuss some style issues, that I'm frequently unsure about:
1. namespace closing brace
It was discussed in http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563
, but with no real result.
When writing headers, do we need the // namespace Foo
On 08/04/2010 03:55 AM, ext Martin Robinson wrote:
Resent from the proper address:
On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson
martin.james.robin...@gmail.com wrote:
I notice that Qt added imageForRendering() and felt they could not use
image() for some reason. I'd be curious if a Qt
On Wed, Aug 4, 2010 at 9:29 AM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Good morning WebKit crowd,
I'd like to discuss some style issues, that I'm frequently unsure about:
1. namespace closing brace
It was discussed in
Am 04.08.2010 um 13:15 schrieb Jeremy Orlow:
On Wed, Aug 4, 2010 at 9:29 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de
wrote:
Good morning WebKit crowd,
I'd like to discuss some style issues, that I'm frequently unsure
about:
1. namespace closing brace
It was discussed in
Looks like it is stuck again, trying to land patch 62961 for the past 8
hours..
Is there any way to see the commit queue script output/console so we can
find out what is going wrong? At times it keeps retrying to land the same
patch multiple times and one of us removes the patch from the queue
It was hung due to https://bugs.webkit.org/show_bug.cgi?id=31500.
I've fixed it now.
Sorry, there isn't a way to see the console output easily. It logs
everything, I just don't post them all online as well as I should.
-eric
On Wed, Aug 4, 2010 at 6:11 AM, Satish Sampath sat...@chromium.org
On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen gga...@apple.com wrote:
Some of us had a somewhat crazy idea to rewrite much of the editing code
(e.g. document.execCommand) in JavaScript.
Pros:
-Ensures that the APIs we expose to the web are at least good enough for our
own editing code
Trying to land the same patch multiple times is expected behavior.
That happens when it can't decide whether the patch is good or bad
(e.g., because the tree is broken or because it's checkout gets out of
date before it's able to actually commit).
Adam
On Wed, Aug 4, 2010 at 6:11 AM, Satish
Agreed, though I have seen at times the same patch was retried 4 or 5 times.
Is that expected?
- Satish
On Wed, Aug 4, 2010 at 5:38 PM, Adam Barth aba...@webkit.org wrote:
Trying to land the same patch multiple times is expected behavior.
That happens when it can't decide whether the patch is
I got a large mail that started with this:
http://build.chromium.org/buildbot/chromiumos/
Automatically closing tree for build image on x86 slab full
I don’t want to receive these mails. I don’t understand them. They are full of
hex numbers that probably relate to git and check-ins in Chromium
We found who started the master and shut it down so this has been fixed, I'm
really sorry about the spam and will make changes so nobody can make this
spam again (+ a filter on non chromium/google email addresses).
M-A
Le 4 août 2010 13:17, Darin Adler da...@apple.com a écrit :
I got a large
On Aug 4, 2010, at 1:29 AM, Nikolas Zimmermann wrote:
1. namespace closing brace
It was discussed in
http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with no
real result.
When writing headers, do we need the // namespace Foo comment after the
namespace closing
I'm confused why a special method is needed though. Can't image() just avoid
the full copy? Given how we use image() in WebKit, I don't think there's any
reason to be concerned if image() continues to reflect the contents of the
ImageBuffer. I think we should just switch to that model for
On Aug 3, 2010, at 4:38 PM, Darin Adler wrote:
Inventing a new layer to rebuild editing on top could well be good. Exposing
that layer itself to webpages seems like it makes the job even harder rather
than easier! Hidden implementation details can be changed more easily than
exposed APIs.
On Aug 4, 2010, at 10:43 AM, Darin Adler wrote:
On Aug 4, 2010, at 1:29 AM, Nikolas Zimmermann wrote:
1. namespace closing brace
It was discussed in
http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with no
real result.
When writing headers, do we need the //
Hi,
Actually, I was questioning also the necessity of this extra buffer.
I'll just give an update and some numbers. We have a very large canvas (few
MB) and our updates are very frequent but very small (clip area is for
example 3x3 pixels), it takes about 25ms for our system to handle the
expose.
The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is
almost exclusively for the purpose of ensuring correct behaviour in the case
where a canvas is drawn onto itself, eg.
context = myCanvas.getContext(2d);
context.drawImage(myCanvas, 0, 0);
Off hand I can think of no
If you'll permit me to expert two of your thoughts:
If we exposed a good set of APIs to JavaScript, then I don't think gluing
will be much of an issue.
And if we did provide a good set of APIs such that web developers themselves
can implement their own editing commands, then there's no
we won't get better APIs if we don't try and the current
APIs suck hard.
Better APIs don't require a rewrite in a new language.
As I just said, a rewrite in a new language seems to be a distraction from
better APIs.
-Ensures that editing code never crashes (outside of JSC/V8 bugs)
Thanks for the clarification. If this is the main reason, then it seems a
valuable optimization to do.
Christophe
On Wed, Aug 4, 2010 at 2:52 PM, Oliver Hunt oli...@apple.com wrote:
The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is
almost exclusively for the purpose
On Wed, Aug 4, 2010 at 3:23 PM, Christophe Public
christophe.pub...@gmail.com wrote:
Thanks for the clarification. If this is the main reason, then it seems a
valuable optimization to do.
Here's the bug for this issue: https://bugs.webkit.org/show_bug.cgi?id=43507
On Wed, Aug 4, 2010 at 2:54 PM, Geoffrey Garen gga...@apple.com wrote:
And if we did provide a good set of APIs such that web developers
themselves can implement their own editing commands, then there's no reason
we can't implement our editing commands in terms of those public APIs,
putting
-Ensures that editing code never crashes (outside of JSC/V8 bugs)
JavaScript can still crash -- you just get an unhandled exception instead
of a segfault. It's not clear to me why that would be better.
I think the kind of crashes Ojan is talking about are ones caused by DOM
mutation
On Aug 4, 2010, at 3:48 PM, Ryosuke Niwa wrote:
I think the kind of crashes Ojan is talking about are ones caused by DOM
mutation events. When we're in a middle of a composite event and fire a
DOMModified or whatever appropriate mutation event is, JavaScript can come in
and remove node,
On Tue, Aug 3, 2010 at 5:06 PM, Simon Fraser simon.fra...@apple.com wrote:
I assume you plan on maintaining support for the DOM Range API?
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html
Yes. We're stuck with them unfortunately.
On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen
29 matches
Mail list logo
