As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for
the Chromium project, we like to make incomplete features available
behind a command line flag to help facilitate testing. I understand
that the norm for WebKit is to only have compile time options for new
/ incomplete features.
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 Fisher wrote:
> As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for
> the Chromium project, we
Perhaps... any suggestions?-Darin
On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth 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 Fisher wrote
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 wrote:
> Perhaps... any suggestions?-Darin
>
>
> On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth wrote:
>
>> Maybe it's worth distinguishing these settings with
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 wrote:
> experiment
With databases, localStorage, and sessionStorage, there is a Settings option
for enabling or disabling the feature. If it's disabled,
DOMWindow::localStorage returns 0 (i.e. null) which is then wrapped in an
object of type Storage by the bindings. This results in |alert((typeof
window.localStorag
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 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 database) t
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 h
On Mon, Sep 21, 2009 at 11:42 AM, Drew Wilson wrote:
> 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 isUndefin
On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov
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.
On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak wrote:
>
> On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
>
> On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov wrote:
>
>>
>> 18.09.2009, в 12:24, Jeremy Orlow написал(а):
>>
>> I'm not sure if we've hit any compatibility issues with thi
On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote:
On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak
wrote:
On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov
wrote:
18.09.2009, в 12:24, Jeremy Orlow написал(а):
I'm not sure if we
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak wrote:
>
> On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote:
>
> On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak wrote:
>
>>
>> On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
>>
>> On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov wrot
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak wrote:
>
> Slightly better. The only real difference it would make is if someone tests
> using a === comparison to undefined (as opposed to == or just a plain
> boolean test).
>
>
One reason why I'm pursuing this is that a naive google developer
Following up on this, because I missed Maciej's response.
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak 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 making it
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
wrote:
Fair enough. But I would be against user-level preferences that add
or remove entire APIs. Rather, the preference should a
On Wed, Sep 23, 2009 at 6:03 PM, Maciej Stachowiak 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 features that
On Sep 23, 2009, at 6:05 PM, Peter Kasting wrote:
On Wed, Sep 23, 2009 at 6:03 PM, Maciej Stachowiak
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
Yeah, I'm thinking A also. OK, sounds like we're on the same page for A
(which is all I really care about). For B it does impact the web app's
ability to do capabilities detection which seems bad, but it's not worth
arguing about hypotheticals I think.
-atw
On Wed, Sep 23, 2009 at 6:10 PM, Maciej
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 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 technique we evangel
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.
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 wr
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 a
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson 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 first runtime switc
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson 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 t
On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson wrote:
>
> On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I'm surprised to see these objections coming up now, weeks after the
>>> original discussion, and only after my patch has
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
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
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>
>
> On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson wrote:
>
>>
>> On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>>
>>> I'm surprised to see these objections coming up now, we
Ooops, meant to reply to all.
On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson wrote:
>
>
> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>
>>
>>
>> That is not true, they are also available in nightly builds at
>> http://nightly.webkit.org/.
>>
>
> I'm not sure what you mean, exactly - the nigh
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 non-
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>
> I'm surprised to see these objections coming up now, weeks after the
>> original discussion, and only after my patch has lande
On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak
wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
wrote:
I'm surprised to see these objections coming up now, weeks after
the original
On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson wrote:
> Ooops, meant to reply to all.
>
>
> On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> That is not true, they are also available in nightly builds at
>>> http://night
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I
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 fo
On Mon, 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 binding
On Mon, 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 binding
On Mon, Oct 5, 2009 at 9:56 PM, Jeremy Orlow wrote:
> On Mon, 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 p
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 wrote:
> On Mon, Oct
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 wrote:
>
> On Oct 5, 2009,
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. I
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig 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
> be prohibitively
On Mon, Oct 5, 2009 at 10:35 PM, Dmitry Titov wrote:
> On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig 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
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 concern
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 shi
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 w
50 matches
Mail list logo
