On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote:
Are there currently any plans for simplifying the situation regarding build
systems? I haven't seen any threads for a while, which I assume means no.
Is there any low hanging fruit out there? Since many of the build systems
are little
On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:
I was wondering if it would be a reasonable change to make accessing
location.href (and other location properties) throw SECURITY_ERR when
accessed across origins (https://webkit.org/b/43504). This initially was
reported on the Chrome
I think doing type checks in the bindings makes sense as a long-term strategy.
Only the bindings level can tell actually detect wrong type errors; the C++
layer can't distinguish wrong type from a validly passed null. WebGL interfaces
are not the only ones that have this problem. Here is a DOM
On Aug 13, 2010, at 2:12 AM, Jeremy Orlow wrote:
On Fri, Aug 13, 2010 at 8:42 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:
I was wondering if it would be a reasonable change to make accessing
location.href (and other location
On multiple occasions, I've been noticing that separating JavaScript for tests
into its own file has been causing me pain. There are several disadvantages
that I know of:
1. One doesn't see test content when a tool (such as run-webkit-tests) sends
them to a failing test. If I want to see it
On Fri, Aug 13, 2010 at 11:17 AM, Alexey Proskuryakov a...@webkit.org wrote:
On multiple occasions, I've been noticing that separating JavaScript for
tests into its own file has been causing me pain. There are several
disadvantages that I know of:
1. One doesn't see test content when a tool
On Aug 13, 2010, at 3:17 AM, Alexey Proskuryakov wrote:
Of course, there is the special case of fast/js tests, which we (I think)
still hope to run without a WebView one day. For that, keeping JS separate is
obviously desirable.
Absolutely agreed - and these can already be run in a
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root
WebKit directory? Perhaps WebCore/platform/graphics or some kind of
/3rparty directory would be better, wouldn't it?
Regards,
Zoltan
___
webkit-dev mailing list
Hi Maciej,
On Aug 13, 2010, at 12:34 AM, Maciej Stachowiak wrote:
On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote:
Are there currently any plans for simplifying the situation regarding build
systems? I haven't seen any threads for a while, which I assume means no.
Is there any low
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't have to have
access control on every document property, only window properties.
I'm not quite sure I understand this. At least for the location
object, I see
On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org wrote:
I've asked Joseph (the original reporter of http://crbug.com/17325)
where he ran into this.
Joseph replied and said While there is a proprietary web app that
relies on this, but it is used at a small company I no longer
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root
WebKit directory? Perhaps WebCore/platform/graphics or some kind of
/3rparty directory would be better, wouldn't it?
ANGLE is a library from Google
http://build.webkit.org/builders/Chromium%20Win%20Release/builds/10478/steps/compile-webkit/logs/stdio
It seems that cr-win for some reason isn't generating the
HTMLEntityTable.cpp file like all the others are.
Is it missing python? (Or python from its path?)
Is there a gyp dependency problem?
Sorry for the spam. I've found the error.
2cygwin - 0 error(s), 0 warning(s)
1Traceback (most recent call last):
1 File ../../WebKitTools/Scripts/create-html-entity-table, line 34, in ?
1import webkitpy.thirdparty.simplejson as simplejson
1 File
14 matches
Mail list logo
