Circling back on this - I have a patch together for the V8 side of this
issue (code generation changes and associated infrastructure). I'm just
waiting for someone to R+ it for me:
https://bugs.webkit.org/show_bug.cgi?id=30240 -- if someone can take a look
at this, I can get this in the tree, and
06.10.2009, в 0:39, Maciej Stachowiak написал(а):
For now, there are no SocketStreamHandle implementation. so even
enabling WebSockets in Settings, it is the almost same that the
feature is not available..
As far as I'm concerned, that's ok for testing, even though we would
not want to
On Oct 5, 2009, at 10:08 PM, Fumitoshi Ukai (鵜飼文敏) wrote:
So, is it fine to make WebSockets enable by default?
For now, there are no SocketStreamHandle implementation. so even
enabling WebSockets in Settings, it is the almost same that the
feature is not available..
As far as I'm
Hi Folks,
I am not happy with the way these runtime settings have been implemented so
far as they break runtime detection using the technique we evangelize to
developers, specifically, using the (property in window) method. A
feature that is turned off at runtime should not be detectable at all,
Agreed. I was similarly dismayed. We are working on rectifying the
problem.
-Darin
On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig sam.wei...@gmail.com wrote:
Hi Folks,
I am not happy with the way these runtime settings have been implemented so
far as they break runtime detection using the
So, two weeks ago I sent an email on this thread stating exactly what I was
planning to do, To whit:
I do think that we ought to be returning undefined instead of null in those
cases, though, just to catch people who are accidentally using isUndefined()
utility functions from common libraries. It
BTW, I modeled my SharedWorker disabling after the code in
JSDOMWindowCustom::audio() that disables the audio constructor on platforms
that don't have MediaPlayer support.
I think the runtime behavior of window.audio and window.SharedWorker should
be identical in practice. Sam, it looks like you
I don't think I wrote the Audio code, (I think I probably just moved it),
but I also don't believe it is intended as a general purpose runtime switch
(but rather fallback when there are no installed codecs). It is also not
something people are going to ship as far as I can tell, and is therefore
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote:
I'm surprised to see these objections coming up now, weeks after the
original discussion, and only after my patch has landed in the tree.
Sorry, I seemed to have missed that thread. I did however file a bug as soon
as the
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote:
I'm surprised to see these objections coming up now, weeks after the
original discussion, and only after my patch has landed in the tree.
Sorry, I
On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote:
I'm surprised to see these objections coming up now, weeks after the
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com
wrote:
I'm surprised to see these objections coming up now, weeks after the
original discussion, and only after my patch has landed in the tree.
Sorry, I seemed to have
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote:
Ooops, meant to reply to all.
On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote:
That is not true, they are also available in nightly builds at
http://nightly.webkit.org/.
I'm not sure what you
window.applicationCache does something different when the runtime switch is
disabled which definitely breaks feature detection. It returns a non-null,
but non-functioning object. At some point I had changed it to return 'null'
when disabled, but later reverted that change and went back to the
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote:
I'm surprised to see these objections coming up now, weeks after the
original discussion, and only
On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson atwil...@google.com wrote:
Ooops, meant to reply to all.
On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote:
That is not true, they are also available
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the
configuration when promoting builds. The bits that passed the test
get promoted.
I'm happy to absorb this cost in the V8 bindings. I don't think it
is important to solve this problem
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote:
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the configuration when
promoting builds. The bits that passed the test get promoted.
I'm happy to absorb this cost in the V8
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote:
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the configuration when
promoting builds. The bits that passed the test get promoted.
I'm happy to absorb this cost in the V8
On Mon, Oct 5, 2009 at 9:56 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote:
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the configuration
when promoting builds. The bits that
On Oct 5, 2009, at 9:54 PM, Mark Rowe wrote:
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the
configuration when promoting builds. The bits that passed the test
get promoted.
I'm happy to absorb this cost in the V8 bindings. I don't
It is requested to be turned on at the beginning of Web Sockets
implementation so that it will be tested as it is brought up.
https://bugs.webkit.org/show_bug.cgi?id=27206
Is is ok to turn off by default from this point of view?
On Tue, Oct 6, 2009 at 1:57 PM, Darin Fisher da...@chromium.org
So, is it fine to make WebSockets enable by default?
For now, there are no SocketStreamHandle implementation. so even enabling
WebSockets in Settings, it is the almost same that the feature is not
available..
--
ukai
On Tue, Oct 6, 2009 at 2:04 PM, Maciej Stachowiak m...@apple.com wrote:
On
I think we should enable Web Sockets in the Chromium Test Shell so that we
can exercise all of the layout tests. (For those not familiar, the Chromium
Test Shell is like DumpRenderTree, but it lives in the Chromium repository.)
I'd imagine that we'd want to enable it in DRT for similar reasons.
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig sam.wei...@gmail.com wrote:
I would still very much like a good solution to runtime enabling/disabling
features in the bindings as I think this would be a useful addition to the
webkit arsenal and I am curious why it is thought that doing it right will
On Mon, Oct 5, 2009 at 10:35 PM, Dmitry Titov dim...@chromium.org wrote:
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig sam.wei...@gmail.com wrote:
I would still very much like a good solution to runtime enabling/disabling
features in the bindings as I think this would be a useful addition to the
Following up on this, because I missed Maciej's response.
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak m...@apple.com wrote:
Fair enough. But I would be against user-level preferences that add or
remove entire APIs. Rather, the preference should affect the behavior of the
API (possibly
On Sep 23, 2009, at 5:24 PM, Drew Wilson wrote:
Following up on this, because I missed Maciej's response.
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak m...@apple.com
wrote:
Fair enough. But I would be against user-level preferences that add
or remove entire APIs. Rather, the
On Wed, Sep 23, 2009 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote:
My thinking on the topic is basically this:
A) For experimental features, it makes sense to make them disappear
completely when turned off, since turning them on is an unusual and
experimental state.
B) For end-user
I think shooting for perfect compatibility might be nice, but is probably
not required.
I do think that we ought to be returning undefined instead of null in those
cases, though, just to catch people who are accidentally using isUndefined()
utility functions from common libraries. It would not be
On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov
a...@webkit.org wrote:
18.09.2009, в 12:24, Jeremy Orlow написал(а):
I'm not sure if we've hit any compatibility issues with this yet,
but it seems quite plausible that someone would
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote:
On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
On Fri, Sep 18, 2009 at 12:59 PM, Alexey
18.09.2009, в 12:24, Jeremy Orlow написал(а):
I'm not sure if we've hit any compatibility issues with this yet,
but it seems quite plausible that someone would compare
window.localStorage (or sessionStorage or database) to undefined
and, since it's null (vs. undefined), their script would
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov a...@webkit.org wrote:
18.09.2009, в 12:24, Jeremy Orlow написал(а):
I'm not sure if we've hit any compatibility issues with this yet, but it
seems quite plausible that someone would compare window.localStorage (or
sessionStorage or
I also have a patch (https://bugs.webkit.org/show_bug.cgi?id=28930) that's
awaiting a resolution of this for desktop notifications. Does anyone object
to putting experimental in the name of the setting as a good solution?
-John
On Wed, Sep 9, 2009 at 9:50 AM, Eric Seidel e...@webkit.org wrote:
Perhaps... any suggestions?-Darin
On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth aba...@webkit.org wrote:
Maybe it's worth distinguishing these settings with some sort of
naming convention so that embedders know they'll be removed at some
point?
Adam
On Tue, Sep 8, 2009 at 11:47 PM, Darin
experimental would be one option. We used to have build-webkit
--svg-experimental iirc.
-eric
On Wed, Sep 9, 2009 at 9:47 AM, Darin Fisher da...@chromium.org wrote:
Perhaps... any suggestions?-Darin
On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth aba...@webkit.org wrote:
Maybe it's worth
40 matches
Mail list logo
