Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-07 Thread Dominic Cooney 
On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:

>
> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>
>
>
> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
>
>>
>> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
>>
>> > Good day, everyone!
>> >
>> > I am sorry if it didn't sound clear enough in our original message,
>> > but we're not proposing a new language support, but we're proposing a
>> > patch which allows others runtimes to run along with JS in the
>> > browser.
>> >
>> > Of course, we're doing this because of our work on Dart, but our
>> > intent was to solicit a feedback from the WebKit community if there is
>> > any interest in supporting runtimes additional to JS (and not JS +
>> > Dart) in the first place.
>> As I have already said, we already support multiple bindings being in use
>> at the same time.
>
>
> Those bindings are different because the code that uses them is not
> activated from web pages. Looking at the specific posted patches, those
> changes seem necessary to support activating a different language from a
> page eg

Re: [webkit-dev] Reg. Direct DOM access without getElementById fails....

2011-12-07 Thread Ariya Hidayat 
> I have facing an issue with Direct DOM  access via "document" object.

Because it is not part of the DOM standard.

This is elementary web stuff, it would be helpful if you would have
done some basic research first as this mailing list is not to teach
people about browser scripting and incompatibilities.



-- 
Ariya Hidayat, http://ariya.ofilabs.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-07 Thread Vijay Menon 
On Tue, Dec 6, 2011 at 11:56 PM, Oliver Hunt  wrote:
>
> On Dec 6, 2011, at 11:53 PM, Oliver Hunt wrote:
>
>
> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>
>
> Those bindings are different because the code that uses them is not
> activated from web pages. Looking at the specific posted patches, those
> changes seem necessary to support activating a different language from a
> page eg

Re: [webkit-dev] For debugging in xcode - Breakpoint does not work.

2011-12-07 Thread Dan Bernstein 


On Dec 6, 2011, at 11:01 PM, Kihong Kwon  wrote:

> Hello.
> 
> I am a new to mac. Can anyone help me for debugging WebCore?
> 
> I have a problem about breakpoint with xcode.
> What I want to say, I can't use a breakpoint with WebCore in the xcode.
> 
> After finish to build webkit, I put a breakpoint to the DOMWindow.cpp
> (I  put a breakpoint to DOMWindow::alert and make a alert for testing)
> But breakpoint does work.
> 
> I did googling for this...
> I found below solution. but It doesn't work too.
> 
> 1. Launch safari.

In order for the instance of Safari you're trying to debug to link against the 
WebCore framework you've built, rather than the system WebCore, you need to 
launch it in a way that sets the DYLD_FRAMEWORK_PATH environment variable to 
point to your build products directory. One easy way to do this is to use 
Tools/Scripts/run-safari. Another way is to add Safari as a custom executable 
to the Xcode project. Also, make sure that you are building all of the projects 
(JavaScriptCore, WebCore, WebKit and WebKit2) and that they're all building 
into the same directory. Again, the build-webkit script takes care of this for 
you.

> 2. Run -> attach to process -> select WebProcess (My XCODE version is 3.2.6)
> 3. Click debug in the WebCore project window.
> 
> Did I make wrong? or have I to do anything else?
> 
> Thanks in advance
> Kihong
> ___
> 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] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-07 Thread David Levin 
On Wed, Dec 7, 2011 at 1:13 AM, Dominic Cooney wrote:

> On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:
>>
>> Web Content Engine The project's primary focus is content deployed on
>> the World Wide Web, using standards-based technologies such as HTML, CSS,
>> JavaScript and the DOM.
>> --Oliver
>>
>
> I intended the question about whether standards compliance was a goal
> rhetorically, in that it seems to me that this goal is honored or ignored
> capriciously.
>

Every issue must be viewed in its own context and conflating them doesn't
help make either issue clearer unless there is concerning pattern (but one
issue isn't that).

With respect to the issue that you're passionate about, Dominic, perhaps a
more targeted conversation is in order.

best wishes,
dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Standard Compliance as a Project Goal (Was WebKit branch to support multiple VMs)

2011-12-07 Thread Ryosuke Niwa 
Starting new thread...

On Wed, Dec 7, 2011 at 1:13 AM, Dominic Cooney wrote:
>
> On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:
>>
>> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>>
>> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
>>
>>>
>>> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
>>>
>>> > Good day, everyone!
>>> >
>>> > I am sorry if it didn't sound clear enough in our original message,
>>> > but we're not proposing a new language support, but we're proposing a
>>> > patch which allows others runtimes to run along with JS in the
>>> > browser.
>>> >
>>> > Of course, we're doing this because of our work on Dart, but our
>>> > intent was to solicit a feedback from the WebKit community if there is
>>> > any interest in supporting runtimes additional to JS (and not JS +
>>> > Dart) in the first place.
>>> As I have already said, we already support multiple bindings being in
>>> use at the same time.
>>
>>
>> Those bindings are different because the code that uses them is not
>> activated from web pages. Looking at the specific posted patches, those
>> changes seem necessary to support activating a different language from a
>> page eg

[webkit-dev] Making empty vectors smaller; eliminate String::adopt(Vector)?

2011-12-07 Thread Darin Adler 
For vectors with no inline capacity, we can store the capacity inside the 
Vector’s buffer. That way, the Vector itself will be one size_t smaller when 
empty. In fact, with a bit of performance risk, we can do the same thing with 
the vector’s size, making an empty Vector just a single pointer. But doing this 
also means that the allocated buffer won’t have the vector elements at the 
start of the memory block. The only thing I could find that this would 
interfere with would be the String::adopt(Vector) function. My question is 
whether with the latest wonderful StringBuilder technology we could eliminate 
String::adopt(Vector). Can we get rid of that entirely from WebKit?

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making empty vectors smaller; eliminate String::adopt(Vector)?

2011-12-07 Thread Adam Barth 
We originally used String::adopt(Vector) in the parser because we
thought it would be faster, but studying profiles and experimenting
with benchmarks revealed that (at least for those use cases) it was
actually slower than just memcpying the data into the String.  I
haven't looked at the other uses of String::adopt(Vector) in the
codebase, but they might also run faster using memcpy.

I think it's probably fine to remove String::adopt(Vector).

Adam


On Wed, Dec 7, 2011 at 10:10 AM, Darin Adler  wrote:
> For vectors with no inline capacity, we can store the capacity inside the 
> Vector’s buffer. That way, the Vector itself will be one size_t smaller when 
> empty. In fact, with a bit of performance risk, we can do the same thing with 
> the vector’s size, making an empty Vector just a single pointer. But doing 
> this also means that the allocated buffer won’t have the vector elements at 
> the start of the memory block. The only thing I could find that this would 
> interfere with would be the String::adopt(Vector) function. My question is 
> whether with the latest wonderful StringBuilder technology we could eliminate 
> String::adopt(Vector). Can we get rid of that entirely from WebKit?
>
> -- Darin
> ___
> 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] Making empty vectors smaller; eliminate String::adopt(Vector)?

2011-12-07 Thread Darin Fisher 
Worst case, if you needed to keep String::adopt(Vector), it seems like you
could
use a bit in StringImpl::m_hashAndFlags to record the fact that the buffer
requires
special "free" handling.

-Darin


On Wed, Dec 7, 2011 at 10:24 AM, Adam Barth  wrote:

> We originally used String::adopt(Vector) in the parser because we
> thought it would be faster, but studying profiles and experimenting
> with benchmarks revealed that (at least for those use cases) it was
> actually slower than just memcpying the data into the String.  I
> haven't looked at the other uses of String::adopt(Vector) in the
> codebase, but they might also run faster using memcpy.
>
> I think it's probably fine to remove String::adopt(Vector).
>
> Adam
>
>
> On Wed, Dec 7, 2011 at 10:10 AM, Darin Adler  wrote:
> > For vectors with no inline capacity, we can store the capacity inside
> the Vector’s buffer. That way, the Vector itself will be one size_t smaller
> when empty. In fact, with a bit of performance risk, we can do the same
> thing with the vector’s size, making an empty Vector just a single pointer.
> But doing this also means that the allocated buffer won’t have the vector
> elements at the start of the memory block. The only thing I could find that
> this would interfere with would be the String::adopt(Vector) function. My
> question is whether with the latest wonderful StringBuilder technology we
> could eliminate String::adopt(Vector). Can we get rid of that entirely from
> WebKit?
> >
> > -- Darin
> > ___
> > 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] Using Go in WebKit

2011-12-07 Thread Ojan Vafai 
Anyone have objections to me using Go for the test results server rewrite?
I don't have any intention of using Go in other places in WebKit. There's a
few reasons this seems fine to me:
1. You already need to get the appengine SDK to interact with the test
results server, so getting the Go appengine SDK instead is not more work.
2. This is a small code base (<1000 lines) and will not be growing much.
3. For the most part, I've been the only one maintaining it for years now
anyways.
4. This code will not depend on anything outside of this directory and
nothing outside this directory will need to depend on this.

FYI, the test results server is the server that stores and serves the JSON
files for the flakiness dashboard (
http://test-results-test.appspot.com/dashboards/flakiness_dashboard.html).

https://bugs.webkit.org/show_bug.cgi?id=73956
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using Go in WebKit

2011-12-07 Thread Filip Pizlo 
Can you comment why you think that Go would be the right tool for the job here, 
as opposed to Python, Perl, Ruby, or something else?  I'm just curious, since I 
have not used Go. :-)

-Filip



On Dec 7, 2011, at 3:39 PM, Ojan Vafai wrote:

> Anyone have objections to me using Go for the test results server rewrite? I 
> don't have any intention of using Go in other places in WebKit. There's a few 
> reasons this seems fine to me:
> 1. You already need to get the appengine SDK to interact with the test 
> results server, so getting the Go appengine SDK instead is not more work.
> 2. This is a small code base (<1000 lines) and will not be growing much.
> 3. For the most part, I've been the only one maintaining it for years now 
> anyways.
> 4. This code will not depend on anything outside of this directory and 
> nothing outside this directory will need to depend on this.
> 
> FYI, the test results server is the server that stores and serves the JSON 
> files for the flakiness dashboard 
> (http://test-results-test.appspot.com/dashboards/flakiness_dashboard.html).
> 
> https://bugs.webkit.org/show_bug.cgi?id=73956
> 
> 
> 
> ___
> 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] Using Go in WebKit

2011-12-07 Thread Ojan Vafai 
I initially started this hoping to address some of the memory problems in
the Python app. It turned out not to fix them in the end, but the new
codebase is better written, much more thoroughly tested and likely more
performant, so I'm inclined to keep it. As for Go vs. Python specifics, I
have opinions that make me prefer Go for this project (e.g. much better
static analysis, likely to perform better, etc), but I'd rather not start a
language discussion on this thread.

On Wed, Dec 7, 2011 at 3:42 PM, Filip Pizlo  wrote:

> Can you comment why you think that Go would be the right tool for the job
> here, as opposed to Python, Perl, Ruby, or something else?  I'm just
> curious, since I have not used Go. :-)
>
> -Filip
>
>
>
> On Dec 7, 2011, at 3:39 PM, Ojan Vafai wrote:
>
> Anyone have objections to me using Go for the test results server rewrite?
> I don't have any intention of using Go in other places in WebKit. There's a
> few reasons this seems fine to me:
> 1. You already need to get the appengine SDK to interact with the test
> results server, so getting the Go appengine SDK instead is not more work.
> 2. This is a small code base (<1000 lines) and will not be growing much.
> 3. For the most part, I've been the only one maintaining it for years now
> anyways.
> 4. This code will not depend on anything outside of this directory and
> nothing outside this directory will need to depend on this.
>
> FYI, the test results server is the server that stores and serves the JSON
> files for the flakiness dashboard (
> http://test-results-test.appspot.com/dashboards/flakiness_dashboard.html).
>
> https://bugs.webkit.org/show_bug.cgi?id=73956
>
>
>
> ___
> 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] Using Go in WebKit

2011-12-07 Thread Dirk Pranke 
All other things being equal, I'd prefer to keep things in Python
since there are a lot more people that can support that than Go. But
if there are some real benefits to Go, I don't have any real
objection.

-- Dirk

On Wed, Dec 7, 2011 at 3:39 PM, Ojan Vafai  wrote:
> Anyone have objections to me using Go for the test results server rewrite? I
> don't have any intention of using Go in other places in WebKit. There's a
> few reasons this seems fine to me:
> 1. You already need to get the appengine SDK to interact with the test
> results server, so getting the Go appengine SDK instead is not more work.
> 2. This is a small code base (<1000 lines) and will not be growing much.
> 3. For the most part, I've been the only one maintaining it for years now
> anyways.
> 4. This code will not depend on anything outside of this directory and
> nothing outside this directory will need to depend on this.
>
> FYI, the test results server is the server that stores and serves the JSON
> files for the flakiness dashboard
> (http://test-results-test.appspot.com/dashboards/flakiness_dashboard.html).
>
> https://bugs.webkit.org/show_bug.cgi?id=73956
>
>
>
>
> ___
> 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] Standard Compliance as a Project Goal (Was WebKit branch to support multiple VMs)

2011-12-07 Thread Dominic Cooney 
First: Oliver and webkit-dev, sorry for the above email; I wrote it in
haste and am now repenting it at leisure.

Ryosuke—you’re right; given that the WebKit project goals page has ten
high-level goals, of course activity is guided by some trade-off between
them.

Dominic

On Thu, Dec 8, 2011 at 3:00 AM, Ryosuke Niwa  wrote:

> Starting new thread...
>
> On Wed, Dec 7, 2011 at 1:13 AM, Dominic Cooney wrote:
>>
>> On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt  wrote:
>>>
>>> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>>>
>>> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
>>>

 On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:

 > Good day, everyone!
 >
 > I am sorry if it didn't sound clear enough in our original message,
 > but we're not proposing a new language support, but we're proposing a
 > patch which allows others runtimes to run along with JS in the
 > browser.
 >
 > Of course, we're doing this because of our work on Dart, but our
 > intent was to solicit a feedback from the WebKit community if there is
 > any interest in supporting runtimes additional to JS (and not JS +
 > Dart) in the first place.
 As I have already said, we already support multiple bindings being in
 use at the same time.
>>>
>>>
>>> Those bindings are different because the code that uses them is not
>>> activated from web pages. Looking at the specific posted patches, those
>>> changes seem necessary to support activating a different language from a
>>> page eg

Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)

2011-12-07 Thread Vincent Hardy 
Hello,

@chris

>> So I take back my statement that CSS Shaders are less dangerous than WebGL. 
>> They are more!!!

It seems to me that the differences are:

a. It is easier to do the timing portion of a timing attack in WebGL because it 
all happens in a script and the timing is precise. With CSS shaders, the timing 
is pretty coarse.

b. The content that a CSS shader has access to may be more sensitive than the 
content a WebGL shader has access to because currently, WebGL cannot render 
HTML (but isn't it possible to render an SVG with a foreignObject containing 
HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't 
the risk be the same? Or is the canvas tainted in that case and cannot be used 
as a texture?).

@charles

>> Can this proposal be moved forward on CORS + HTMLMediaElement, 
>> HTMLImageElement and HTMLCanvasElement?

At the last FX meeting, I got an action to sync. up with the CORS group and 
discuss how CORS would apply to CSS shaders.

Cheers,
Vincent

Date: Mon, 05 Dec 2011 15:59:14 -0800
From: Charles Pritchard mailto:ch...@jumis.com>>
To: Chris Marrin mailto:cmar...@apple.com>>
Cc: Jonas Sicking mailto:jo...@sicking.cc>>, 
webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:
Security problems with CSS shaders)
Message-ID: <4edd5ad2.4010...@jumis.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 12/5/11 3:34 PM, Chris Marrin wrote:
On Dec 5, 2011, at 11:32 AM, Adam Barth wrote:

On Mon, Dec 5, 2011 at 10:53 AM, Chris 
Marrinmailto:cmar...@apple.com>>  wrote:
To be clear, it's not the difference between white and black pixels, it's
the difference between pixels with transparency and those without.
Can you explain why the attack is limited to distinguishing between
black and transparent pixels?  My understanding is that these attacks
are capable of distinguishing arbitrary pixel values.
This is my misunderstanding. I was referring to the attacks using WebGL, which 
measure the difference between rendering alpha and non-alpha pixels. But I 
think there is another, more dangerous attack vector specific to CSS shaders. 
Shaders have the source image (the image of that part of the page) available. 
So it is an easy thing to make a certain color pixel take a lot longer to 
render (your "1000x slower" case). So you can easily and quickly detect, for 
instance, the color of a link.

Can this proposal be moved forward on CORS + HTMLMediaElement,
HTMLImageElement and HTMLCanvasElement?

The proposal would really benefit users and authors on those media
types, even if it falls short of applying to general HTML elements and
CSS urls in the first draft.

I realize that it falls short of the lofty goals of the presentation,
but it would make a good impact and set the stage for further work. It
seems entirely do-able to disable a:visited on elements that have custom
filters applied, but, like the timing issues, there needs to be some
empirical data on risks before moving forward on them.

So I take back my statement that CSS Shaders are less dangerous than WebGL. 
They are more!!! As I've said many times (with many more expletives), I hate 
the Internet.

I think the solution is clear. We should create a whole new internet where we 
only let in people we trust.  :-)

-
~Chris
cmar...@apple.com

I still love my iPhone. ;-)


-Charles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)

2011-12-07 Thread Adam Barth 
On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy  wrote:
> @chris
>
>>> So I take back my statement that CSS Shaders are less dangerous than
>>> WebGL. They are more!!!
>
> It seems to me that the differences are:
>
> a. It is easier to do the timing portion of a timing attack in WebGL because
> it all happens in a script and the timing is precise. With CSS shaders, the
> timing is pretty coarse.
>
> b. The content that a CSS shader has access to may be more sensitive than
> the content a WebGL shader has access to because currently, WebGL cannot
> render HTML (but isn't it possible to render an SVG with a foreignObject
> containing HTML into a 2D canvas, and then use that as a texture? In that
> case, wouldn't the risk be the same? Or is the canvas tainted in that case
> and cannot be used as a texture?).

Bear in mind that these security problems have been addressed in
WebGL.  WebGL no long suffers from these vulnerabilities.

> @charles
>
>>> Can this proposal be moved forward on CORS +
>>> HTMLMediaElement, HTMLImageElement and HTMLCanvasElement?
>
> At the last FX meeting, I got an action to sync. up with the CORS group and
> discuss how CORS would apply to CSS shaders.

It's very unclear to me how CORS can help in this situation.  Can you
explain what you have in mind?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making empty vectors smaller; eliminate String::adopt(Vector)?

2011-12-07 Thread Ryosuke Niwa 
On Wed, Dec 7, 2011 at 10:10 AM, Darin Adler  wrote:

> For vectors with no inline capacity, we can store the capacity inside the
> Vector’s buffer. That way, the Vector itself will be one size_t smaller
> when empty. In fact, with a bit of performance risk, we can do the same
> thing with the vector’s size, making an empty Vector just a single pointer.
> But doing this also means that the allocated buffer won’t have the vector
> elements at the start of the memory block. The only thing I could find that
> this would interfere with would be the String::adopt(Vector) function. My
> question is whether with the latest wonderful StringBuilder technology we
> could eliminate String::adopt(Vector). Can we get rid of that entirely from
> WebKit?
>

I support this change and I think we can make this change.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev