Matching IE and FF means we shouldn't suffer too much in terms of
incompatibilities. Of course, there could be some WebKit specific content
out there that would break.
This seems like a worthwhile change to try out.
-Darin
On Thu, Aug 12, 2010 at 8:08 PM, Mihai Parparita wrote:
> I was wonder
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 side (http://crbug.com/17325), but it looks like
neither the JSC
As I mentioned, I am not necessarily against ever changing the behavior, but
if we do, we should make sure to remove all the existing checks, as they
become an unnecessary branch. It just seems to me like that should be a
separate change than a bug due to ambiguity.
-Sam
On Thu, Aug 12, 2010 at
For what it's worth, I think this change should be made for all of the
DOM bindings, not just those for WebGL. The IDL code generators'
support for overloaded methods already generates TypeError when an
incoming argument doesn't implement any of the interfaces required by
the overloaded variants. T
Hardly. Right now we already do the type checking in the generated
toType(argument) functions. Instead of casting to null, we throw a
TypeError, which adds no extra cost if the type is correct.
Besides, where I looked, after toType(argument) call, exception is
checked. Only that currently toTyp
An added benefit of removing the VS build system first would be that we'd be
able to build using VS2005 or VS2008.
On Thu, Aug 12, 2010 at 10:36 AM, Adam Barth wrote:
> Eric and I discussed this recently. We think the easiest path forward
> is to try to remove build systems incrementally. Each
Eric and I discussed this recently. We think the easiest path forward
is to try to remove build systems incrementally. Each build system we
remove makes it easier to hack on the project because you have one
less build system to worry about. The easiest build system to remove
is probably the Visu
On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher wrote:
> On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig wrote:
>
>> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
>>
>>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
>>>
For this specific case, it seems like you could easily check f
Hi Jeremy,
On Aug 12, 2010, at 7:37 AM, Jeremy Orlow wrote:
> On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer wrote:
> On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc wrote:
>
> > i completely agree with jeremy. is it possible to at least drop the cryptic
> > hashcodes/timestamps? without them, t
Let me re-iterate (because even some co-workers are getting confused): I'm
not secretly trying to get the mac port to start using GYP. (Or saying it's
a bad idea either, mind you.) I'm just concerned that the process
associated with adding a file (or adding a dependency between projects on
the ma
On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer wrote:
> On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc wrote:
>
> > i completely agree with jeremy. is it possible to at least drop the
> cryptic hashcodes/timestamps? without them, the .xcodeproj files should at
> least be editable by hand.
>
> Does
That should work too.
mo
On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc wrote:
>> so i think we just need to change toJS/toV8...
>
> sorry, i meant to(), not toJS/toV8.
>
>>
>> dumi
>>
>> On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao wrote:
>>>
>>> Actually it's a different issue. What we w
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc wrote:
> i completely agree with jeremy. is it possible to at least drop the cryptic
> hashcodes/timestamps? without them, the .xcodeproj files should at least be
> editable by hand.
Doesn't gyp already generate Xcode projects for Chrome? I think
On Aug 9, 2010, at 3:48 PM, ext Pavel Feldman wrote:
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 our
>
> In addition, has anyone ever looked at simplifying the mac port's xcode
> project? It's _by far_ the heaviest burden on the project given that you
> pretty much need to use xcode (which is mac only...no other port requires
> this), exported linker symbols are in a separate file, extra effort t
>
> so i think we just need to change toJS/toV8...
sorry, i meant to(), not toJS/toV8.
>
> dumi
>
>
> On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao wrote:
>
>> Actually it's a different issue. What we want to do is not enforcing
>> full arguments, but if an input argument is the wrong type, w
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 more than lists of files, it really seems like we should be a
if converting a JS argument to the type declared in the IDL file throws an
exception, the auto-generated code will throw a TYPE_MISMATCH_ERR. so i
think we just need to change toJS/toV8 to throw exceptions when conversions
fails instead of returning NULL (toString(), toInt32(), etc. already do
that
18 matches
Mail list logo
