Re: [webkit-dev] GlobalScript API.

[Alex Russell]

On Tue, Sep 1, 2009 at 9:58 PM, Ojan Vafai wrote:
> On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt  wrote:
>>
>> On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:
>>
>> Thanks a lot Maciej!
>> As a note to the API described in this thread: there was a proposal in
>> private thread to replace the JS constructor with 4 parameters with a tag:
>> instead of
>> var globalScript = new webkitGlobalScript(name, url, loadHandler,
>> errorHandler);
>
> I know this as been discussed a million times already, but this bugs me.
> What if you want to load multiple scripts or populate a globalscript from
> the parent page(s)? I prefer the other importScript-like ideas.
> I'd much prefer if we made creating a globalScript synchronous and with no
> network request. The async load of iframes with an empty src is really
> frustrating to web developers and causes lots of bugs and performance
> problems in practice.
> If we keep this syntax, we should at least try and special-case leaving out
> the url argument so that we load the globalscript synchronously. I'm not
> sure if this is really feasible given the time it takes to create a
> Document, but we should at least try it and measure the performance..

Not to harp, but for lack of a missing abstraction (Deferreds or
Futures, or whatever your particular CS dept called them), we've seen
every JS library on the planet re-invent some "onready" abstraction
when the built-in events don't quite cover it. This is just another
place where having a uniform for way to listen for a single event
(which possibly already happened) would turn this into a simpler
problem.

Something like:

var globalScript = new webkitGlobalScript(name);

// ...time/flow control passes...

globalScript.onready(handler);

// ...time passes

globalScript.src = "";

// ...time passes, ready happens

// handler is called immediately on registration since future already arrived.
globalScript.onready(anotherHandler);

Regards

>> to have this:
>> > onerror=...>
>>
>> This actually displays one of the issues i have with global script as a
>> concept, you are basically just doing
>> 
>> And that gives you a context that achieves almost everything the global
>> script concept gives you.
>
> People keep saying that this is no better than a new window or an iframe
> because you can script those synchronously across pages, but that totally
> misses the point. The the frame/script/window survives when it's parent page
> is closed if there's another page pointing to it and, in some versions of
> this proposal, it survives same-origin page navigations. That isn't true of
> iframes or windows and is exactly what makes these useful.
> For the record, I'm on the fence about this idea, but it seems worth
> experimenting with if there are web pages that will follow through with
> using them, understanding that they're experimental APIs of course.
> Ojan
> ___
> 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] GlobalScript API.

[Ojan Vafai]

On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt  wrote:

> On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:
>
> Thanks a lot Maciej!
> As a note to the API described in this thread: there was a proposal in
> private thread to replace the JS constructor with 4 parameters with a tag:
>
> instead of
> var globalScript = new webkitGlobalScript(name, url, loadHandler,
> errorHandler);
>
> I know this as been discussed a million times already, but this bugs me.
What if you want to load multiple scripts or populate a globalscript from
the parent page(s)? I prefer the other importScript-like ideas.

I'd much prefer if we made creating a globalScript synchronous and with no
network request. The async load of iframes with an empty src is really
frustrating to web developers and causes lots of bugs and performance
problems in practice.

If we keep this syntax, we should at least try and special-case leaving out
the url argument so that we load the globalscript synchronously. I'm not
sure if this is really feasible given the time it takes to create a
Document, but we should at least try it and measure the performance..

> to have this:
>  onerror=...>
>
> This actually displays one of the issues i have with global script as a
> concept, you are basically just doing
>
> And that gives you a context that achieves almost everything the global
> script concept gives you.
>

People keep saying that this is no better than a new window or an iframe
because you can script those synchronously across pages, but that totally
misses the point. The the frame/script/window survives when it's parent page
is closed if there's another page pointing to it and, in some versions of
this proposal, it survives same-origin page navigations. That isn't true of
iframes or windows and is exactly what makes these useful.

For the record, I'm on the fence about this idea, but it seems worth
experimenting with if there are web pages that will follow through with
using them, understanding that they're experimental APIs of course.

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

Re: [webkit-dev] GlobalScript API.

[Leo Meyerovich]

Perhaps worth reexamining lessons learned from (PLT?) Scheme's 
distinction between units and modules.


Security, assuming & beyond the SOP, is worth considering. Module 
loading would be a giant boon for writing secure apps if the loader can 
specify the load environment (e.g., empty it, share the DOM / 
prototypes, or stipulate fresh / isolated ones). It's unclear what 
guarantees the loadee would want (e.g., frame-busting)... perhaps a 
discussion that could be more informed by the OCaps list that is active 
in the basic topic.


- Leo



Patrick Mueller wrote:

Patrick Mueller wrote:

Dmitry Titov wrote:



Here is an actual API:
---
Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);


I've mentioned before that this API turns out to be very similiar to 
the serverJS notion of a "module".


https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

Differences are the name: require -> webkitGlobalScript; semantics 
about sharing across pages (not relevant to the serverJS work); the 
"exports" variable in the module which provides the reference to the 
globalScript return value the client sees; and that this is async vs. 
serverJS's sync model.


Of most interest is the notion of the "exports" variable.  Instead of 
exposing the "global" scope of the global script itself as the return 
value, you actually have to assign something to the exports variable 
from within the global script for it to be available in the caller.  
The nice thing about this is that it provides a nice way to create 
private references within your global script.


Another interesting aspect of this is that it easily allows a global 
script author to use some library without that library infecting the 
pages' (clients of the global scope) scopes.  For instance, one global 
script could pull in jQuery, another could pull in Prototype, or a 
different version of jQuery.  Since only properties specfically added 
to "exports" are available to pages' scopes, there's no negative 
interaction between jQuery and Prototype.  They live in the "globals" 
of each global script, which aren't visible to anyone else.


Of course, monkey patching is still a problem - or is it?  Does each 
page scope and global scope get it's own set of globals?  eg, only one 
Object object? I was thinking originally that you'd want to share 
built in globals like Object and Array, but now I don't see how that 
would be possible.




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

Re: [webkit-dev] GlobalScript API.

[Oliver Hunt]

On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:


Thanks a lot Maciej!

As a note to the API described in this thread: there was a proposal  
in private thread to replace the JS constructor with 4 parameters  
with a tag:


instead of
var globalScript = new webkitGlobalScript(name, url, loadHandler,  
errorHandler);


to have this:
webkit-globalscript>
This actually displays one of the issues i have with global script as  
a concept, you are basically just doing



And that gives you a context that achieves almost everything the  
global script concept gives you.


--Oliver

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

Re: [webkit-dev] GlobalScript API.

[Patrick Mueller]

Patrick Mueller wrote:

Dmitry Titov wrote:



Here is an actual API:
---
Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);


I've mentioned before that this API turns out to be very similiar to the 
serverJS notion of a "module".


https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

Differences are the name: require -> webkitGlobalScript; semantics about 
sharing across pages (not relevant to the serverJS work); the "exports" 
variable in the module which provides the reference to the globalScript 
return value the client sees; and that this is async vs. serverJS's sync 
model.


Of most interest is the notion of the "exports" variable.  Instead of 
exposing the "global" scope of the global script itself as the return 
value, you actually have to assign something to the exports variable 
from within the global script for it to be available in the caller.  The 
nice thing about this is that it provides a nice way to create private 
references within your global script.


Another interesting aspect of this is that it easily allows a global 
script author to use some library without that library infecting the 
pages' (clients of the global scope) scopes.  For instance, one global 
script could pull in jQuery, another could pull in Prototype, or a 
different version of jQuery.  Since only properties specfically added to 
"exports" are available to pages' scopes, there's no negative 
interaction between jQuery and Prototype.  They live in the "globals" of 
each global script, which aren't visible to anyone else.


Of course, monkey patching is still a problem - or is it?  Does each 
page scope and global scope get it's own set of globals?  eg, only one 
Object object? I was thinking originally that you'd want to share built 
in globals like Object and Array, but now I don't see how that would be 
possible.


--
Patrick Mueller - http://muellerware.org

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

Re: [webkit-dev] GlobalScript API.

[Patrick Mueller]

Dmitry Titov wrote:

Thanks a lot Maciej!
As a note to the API described in this thread: there was a proposal in
private thread to replace the JS constructor with 4 parameters with a tag:

instead of
var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);

to have this:



My initial reaction is ... urghhh ...



The first tag with a specific name that provides a src or inline script or
injected with innerText would effectively supply 'initial script'. The
later-encountered tags withthe same name would have their initial script
ignored and simply connected to the same one. The tag's DOM element would be
EventTarget (for load and error) and have a 'context' property to pull the
global scope object of the script.


The element is much less flexible than JavaScript APIs.  For instance, I 
can imagine I may want to conditionally use a global script.  If we only 
had the element, I'd have to construct one in JS, then inject it into 
the DOM.  Calling a constructor would be a lot less work.  :-)


--
Patrick Mueller - http://muellerware.org

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

Re: [webkit-dev] GlobalScript API.

[Maciej Stachowiak]

On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:


Thanks a lot Maciej!

As a note to the API described in this thread: there was a proposal  
in private thread to replace the JS constructor with 4 parameters  
with a tag:


instead of
var globalScript = new webkitGlobalScript(name, url, loadHandler,  
errorHandler);


to have this:
webkit-globalscript>


The first tag with a specific name that provides a src or inline  
script or injected with innerText would effectively supply 'initial  
script'. The later-encountered tags withthe same name would have  
their initial script ignored and simply connected to the same one.  
The tag's DOM element would be EventTarget (for load and error) and  
have a 'context' property to pull the global scope object of the  
script.


Why is a tag better for this than a constructor or function?

Regards,
Maciej



Dmitry

On Mon, Aug 31, 2009 at 7:18 PM, Maciej Stachowiak   
wrote:


On Aug 31, 2009, at 6:09 PM, Dmitry Titov wrote:


Hi WebKit-dev,

I'm hoping to get your advice on Global Script proposal and how to  
start implementing it as an 'experimental API' since it's not  
standardized yet.


As part of work on Workers in WebKit and Chromium, we discussed  
them with our web application folks (mostly gmail). We came to the  
idea that in addition to workers, they need a shared script context  
which runs on the same UI thread and directly scriptable.


Our previous take (with an invisible window running all the time in  
the background) was not that fruitful but it indicated the way to  
go. We are thankful to the members of the whatwg community for the  
detailed threat analysis of 'permanently running invisible pages',  
it helped very much. Not right away but it was absorbed :-) Current  
proposal reflects realization that there is a less-powerful way to  
achieve the same benefits.


I'm looking for a way to implement it as an experimental API in  
WebKit and Chromium. I'm thinking it can go the similar way as  
webkitNotifications - surrounded by ENABLE(GLOBAL_SCRIPT) and  
prefixed with 'webkit' to keep the difference.


Here's what I think we should take a look at:

1) Does this proposal have a potential standards-track future?  
Relevant specific issues would be interest from other browser  
vendors and standards folks, interest from content producers, and  
our own degree of confidence that this is the right approach. Note:  
in some cases a prototype can be the best way to address concerns,  
however. In some cases we're willing to add proprietary extensions  
that have little hope of ever becoming a standard, but almost always  
we do this for the sake of non-browser use.


2) Do we have some agreement in the WebKit community that this is a  
good approach? It would be good for us to do some of our own design  
review, if this isn't going to be a standard in the foreseeable  
future.


If we are optimistic about the future, then an ENABLE macro and a  
WebKit prefix would be a good way to handle things.


I will do some detailed design review soon.

Regards,
Maciej



I'd appreciate much your advice on the whole API and on the way to  
bring it into WebKit.


Here is a link to the whatwg thread, with the proposal and use  
cases: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html


Here is an actual API:
---
Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler,  
errorHandler);


This returns a global scope object for the named Global Script.
If one does not exist yet, creates a new one. The globalScript is
sharing same process and same thread as the page running the  
constructor

and is operational right away. No synchronization is necessary.
Parameters:
name - string identifying the global script. Scoped to the orogin.
url  - the JS resource to load, if it was not yet loaded. If the  
Global Script is already loaded but from a different url - the  
error is raised.
laodHandler - a function called asynchronously when the script is  
loaded (or if it was already loaded by another page)
errorHandler - handler for loading errors, like violation of same- 
origin policy or network error


The GlobalScript would create its own ScriptExecutionContext- 
derived context if it was not yet created, and start to load the  
script into it. Once the script is loaded, it is evaluated in the  
global scope of the Global Script and loadHandlers are executed.  
Other pages that create a Global Script with the same name in the  
same origin would get the same object back.


The globalScript object returned from the constructor can be  
immediately used to set/retrieve properties and event handlers on it.


API exposed to Global Script (on its global scope object)
- Timers
- XHR
- Navigator
- localStorage
- Database
- Workers
-

Thanks,
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mail

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Tuesday, September 1, 2009 at 12:59:10 PM, Adam Roben wrote:

> So, I propose that we change the prepare-ChangeLog template to the following:
> 
> 2009-09-01  Adam Roben  
> 
> Reviewed by NOBODY (OOPS!)
> 
> Need a short description of this patch (OOPS!)
> 
> Need a bug title and URL (OOPS!)
> 
> What do others think?


Not git-friendly enough, IMO.  I like this better:

2009-09-01  Adam Roben  

Need a bug title and URL (OOPS!)

Reviewed by NOBODY (OOPS!)

Need a short description of this patch (OOPS!)



Dave

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Sep 1, 2009, at 12:59 PM, Adam Roben wrote:


On Jul 9, 2009, at 4:32 AM, Maciej Stachowiak wrote:

How about this as the canonical format (with prepare-ChangeLog  
encouraging it)?


2009-07-08  Maciej Stachowiak  

  Make prepare-ChangeLog less shouty
  https://bugs.webkit.org/show_bug.cgi?id=27098

  Reviewed by Mark Rowe.

  * Scripts/prepare-ChangeLog:


This format seems good when the patch in question actually fixes the  
bug. But in cases where a bug requires multiple changes to be fixed,  
I find this format confusing. For example, here's the top of the  
ChangeLog from r47943 :



2009-09-01  Brady Eidson  

  Reviewed by Sam Weinig.

  Page Cache should support pages with frames
  https://bugs.webkit.org/show_bug.cgi?id=13631


When I saw this, I assumed that r47943 was changing WebKit/WebCore  
so that the page cache would support pages with frames. But it turns  
out that r47943 was just one step along the path to making that  
happen.


What I like to do in cases like this is to start the ChangeLog with  
a short description of what *this patch* does. Here's an example  
(from r44269 ):



2009-05-29  Adam Roben  

  Make sure PlatformMouseEvent::modifierFlags contains MK_ALT  
when the

  Alt key is pressed

  First part of fixing Bug 25729: Alt-clicking a link doesn't  
start a

  download
  https://bugs.webkit.org/show_bug.cgi?id=25729

  Reviewed by Darin Adler.


I think the bug title and URL should be above the brief description of  
what this particular patch does. I don't like the bug URL being so far  
down.




(You can ignore the "First part of fixing Bug 25729: " part -- I  
know some people dislike that and I'm not advocating it as part of  
this email.)


So, I propose that we change the prepare-ChangeLog template to the  
following:


2009-09-01  Adam Roben  

   Reviewed by NOBODY (OOPS!)

   Need a short description of this patch (OOPS!)

   Need a bug title and URL (OOPS!)


What do others think?


I'd swap the last two. Maybe we could make the bug URL nag say "Need a  
bug title and URL - if a partial fix please say so (OOPS!)"


Regards,
Maciej

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

Re: [webkit-dev] GlobalScript API.

[Dmitry Titov]

Thanks a lot Maciej!
As a note to the API described in this thread: there was a proposal in
private thread to replace the JS constructor with 4 parameters with a tag:

instead of
var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);

to have this:


The first tag with a specific name that provides a src or inline script or
injected with innerText would effectively supply 'initial script'. The
later-encountered tags withthe same name would have their initial script
ignored and simply connected to the same one. The tag's DOM element would be
EventTarget (for load and error) and have a 'context' property to pull the
global scope object of the script.

Dmitry

On Mon, Aug 31, 2009 at 7:18 PM, Maciej Stachowiak  wrote:

>
> On Aug 31, 2009, at 6:09 PM, Dmitry Titov wrote:
>
> Hi WebKit-dev,
>
> I'm hoping to get your advice on Global Script proposal and how to start
> implementing it as an 'experimental API' since it's not standardized yet.
>
> As part of work on Workers in WebKit and Chromium, we discussed them with
> our web application folks (mostly gmail). We came to the idea that in
> addition to workers, they need a shared script context which runs on the
> same UI thread and directly scriptable.
>
> Our previous take (with an invisible window running all the time in the
> background) was not that fruitful but it indicated the way to go. We are
> thankful to the members of the whatwg community for the detailed threat
> analysis of 'permanently running invisible pages', it helped very much. Not
> right away but it was absorbed :-) Current proposal reflects realization
> that there is a less-powerful way to achieve the same benefits.
>
> I'm looking for a way to implement it as an experimental API in WebKit and
> Chromium. I'm thinking it can go the similar way as webkitNotifications -
> surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the
> difference.
>
>
> Here's what I think we should take a look at:
>
> 1) Does this proposal have a potential standards-track future? Relevant
> specific issues would be interest from other browser vendors and standards
> folks, interest from content producers, and our own degree of confidence
> that this is the right approach. Note: in some cases a prototype can be the
> best way to address concerns, however. In some cases we're willing to add
> proprietary extensions that have little hope of ever becoming a standard,
> but almost always we do this for the sake of non-browser use.
>
> 2) Do we have some agreement in the WebKit community that this is a good
> approach? It would be good for us to do some of our own design review, if
> this isn't going to be a standard in the foreseeable future.
>
> If we are optimistic about the future, then an ENABLE macro and a WebKit
> prefix would be a good way to handle things.
>
> I will do some detailed design review soon.
>
> Regards,
> Maciej
>
>
> I'd appreciate much your advice on the whole API and on the way to bring it
> into WebKit.
>
> Here is a link to the whatwg thread, with the proposal and use cases:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html
>
> Here is an actual API:
> ---
> Page-level API
>
> var globalScript = new webkitGlobalScript(name, url, loadHandler,
> errorHandler);
>
> This returns a global scope object for the named Global Script.
> If one does not exist yet, creates a new one. The globalScript is
> sharing same process and same thread as the page running the constructor
> and is operational right away. No synchronization is necessary.
> Parameters:
> name - string identifying the global script. Scoped to the orogin.
> url  - the JS resource to load, if it was not yet loaded. If the Global
> Script is already loaded but from a different url - the error is raised.
> laodHandler - a function called asynchronously when the script is loaded
> (or if it was already loaded by another page)
> errorHandler - handler for loading errors, like violation of same-origin
> policy or network error
>
> The GlobalScript would create its own ScriptExecutionContext-derived
> context if it was not yet created, and start to load the script into it.
> Once the script is loaded, it is evaluated in the global scope of the Global
> Script and loadHandlers are executed. Other pages that create a Global
> Script with the same name in the same origin would get the same object back.
>
> The globalScript object returned from the constructor can be immediately
> used to set/retrieve properties and event handlers on it.
>
> API exposed to Global Script (on its global scope object)
> - Timers
> - XHR
> - Navigator
> - localStorage
> - Database
> - Workers
> -
>
> Thanks,
> Dmitry
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mai

Re: [webkit-dev] Changes to prepare-ChangeLog

[Brady Eidson]

On Sep 1, 2009, at 12:59 PM, Adam Roben wrote:



2009-09-01  Adam Roben  

   Reviewed by NOBODY (OOPS!)

   Need a short description of this patch (OOPS!)

   Need a bug title and URL (OOPS!)


What do others think?


With the detriment of adding Y.A.O. (yet another OOPS!) to the  
ChangeLog template, I like this.


~Brady


-Adam

___
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] Changes to prepare-ChangeLog

[Adam Roben]

On Jul 9, 2009, at 4:32 AM, Maciej Stachowiak wrote:

How about this as the canonical format (with prepare-ChangeLog  
encouraging it)?


2009-07-08  Maciej Stachowiak  

   Make prepare-ChangeLog less shouty
   https://bugs.webkit.org/show_bug.cgi?id=27098

   Reviewed by Mark Rowe.

   * Scripts/prepare-ChangeLog:


This format seems good when the patch in question actually fixes the  
bug. But in cases where a bug requires multiple changes to be fixed, I  
find this format confusing. For example, here's the top of the  
ChangeLog from r47943 :



2009-09-01  Brady Eidson  

   Reviewed by Sam Weinig.

   Page Cache should support pages with frames
   https://bugs.webkit.org/show_bug.cgi?id=13631


When I saw this, I assumed that r47943 was changing WebKit/WebCore so  
that the page cache would support pages with frames. But it turns out  
that r47943 was just one step along the path to making that happen.


What I like to do in cases like this is to start the ChangeLog with a  
short description of what *this patch* does. Here's an example (from  
r44269 ):



2009-05-29  Adam Roben  

   Make sure PlatformMouseEvent::modifierFlags contains MK_ALT  
when the

   Alt key is pressed

   First part of fixing Bug 25729: Alt-clicking a link doesn't  
start a

   download
   https://bugs.webkit.org/show_bug.cgi?id=25729

   Reviewed by Darin Adler.


(You can ignore the "First part of fixing Bug 25729: " part -- I know  
some people dislike that and I'm not advocating it as part of this  
email.)


So, I propose that we change the prepare-ChangeLog template to the  
following:


2009-09-01  Adam Roben  

Reviewed by NOBODY (OOPS!)

Need a short description of this patch (OOPS!)

Need a bug title and URL (OOPS!)


What do others think?

-Adam

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

Re: [webkit-dev] New marking model for GC collected objects

[Geoffrey Garen]

Hi Zoltan.

JSWrapperObject::markChildren is responsible for marking the  
internalValue of a DateInstance. Is that function not being called?


Geoff

On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:


Hi Oliver,

it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date
object is sometimes freed by the garbage collector.

More specifically:
The double (millisecond) representation of a date object (returned  
by a
"new Date" expression) is stored in JSWrapperObject:  
m_internalValue. This
m_internalValue points to a JSNumberCell, which stores the double  
value.
Although this JSNumberCell is referenced by m_internalValue, the GC  
still

collects its memory space.

How can I fix this bug with the new mark() model?

Zoltan


Last night I landed a patch that replaces the old recursive marking
functions with a new iterative model that uses an explicit mark
stack.  This means that any custom mark methods that you need to  
write
now need to be slightly different from what they were previously,  
i'll

attempt to summarise here.

The most obvious change is that an object is no longer responsible  
for

marking itself instead the recursive mark methods have been replaced
by a new virtual markChildren(MarkStack&) which is responsible for
appending an objects children to the stack.

The MarkStack is a very simple class, and the only method you really
need to know about is MarkStack::append which adds a new object to  
the

stack.

The changes to how your custom marking functions are implemented are
trivial, but here's a simple example
void MyAwesomeObject::mark()
{
Base::mark();
if (!m_child.marked())
m_child.mark();
}

Becomes
void MyAwesomeObject::markChildren(MarkStack& markStack)
{
Base::markChildren(markStack);
markStack.append(m_child);
}

And that's it, you're done.

It's important to note that you will never be in a position where you
call markChildren yourself, if you are that is an error.

--Oliver

___
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

Re: [webkit-dev] [webkit]Incrementing problem in css

[Shinichiro Hamaji]

Hi,
I believe this is the bug you are pointing.

https://bugs.webkit.org/show_bug.cgi?id=23262

I put a patch which may fix the issue, unfortunately this isn't reviewed yet
though (could someone review this please ? :)

On Tue, Sep 1, 2009 at 4:36 PM, Simon Fraser  wrote:

> On Sep 1, 2009, at 6:13 AM, hodovan.ren...@stud.u-szeged.hu wrote:
>
>  Hi All!
>>
>> Running some LaoutTests I found the following:
>> There is an increment object in css. If the children of this object was
>> modified (append or remove), then the rest of the list wasn't adapt to this.
>> E.g.: append to 1-2-3-4 one more element at position 2 the result is:
>> 1-2-2-3-4.
>> remove from the same the second element: 1-3-4. Testing it in firefox and
>> opera the results are 1-2-3-4 and 1-2-3. Unfortunatly Safari (on Windows)
>> doesn't adapt as well. I feel this dynamic adaptation has not yet
>> implemented, am I rigth?
>> If so I would try to implement it myself. Any help or suggestion to do
>> this is welcome.
>>
>
> You should look for an existing bugzilla bug on this issue, and if there
> isn't one, file a new bug with a simple testcase. Then feel free to start
> working on it.
>
> Simon
>
>
> ___
> 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] Qtish API for JavaScriptCore

[Oliver Hunt]

On Sep 1, 2009, at 10:30 AM, Kent Hansen wrote:


Hi Oliver,

ext Oliver Hunt wrote:

I am concerned about the performance impact of changing
getPropertyNames, as well as correctness -- getPropertyNames does
specifically exist for the support of for..in enumeration.



Any concerns about adding a separate function for that, then (i.e.
getNonEnumerablePropertyNames())? JSC would not use that function
itself, it would just give us a chance to introspect JS objects and  
our

own host objects. Of course, it'd mean keeping that function working
whenever there's e.g. a refactoring/restructuring of
JSObject::getPropertyNames() (only once every full moon, right? :-) ).


We'll probably need this logic for Object.getPropertyNames in ES5, my  
concern is the implementation and performance impact, as well as  
correctness in the context of caching.



- Being able to delete a property from C++ even if the property has
DontDelete=true. We implemented this by adding a checkDelete
argument to
JSObject::deleteProperty(). I think it's similar in spirit to the  
put

()
methods that have a checkReadOnly argument. The patch is not that
large
compared to the getPropertyNames() change, because there aren't as
many
classes reimplementing deleteProperty().



I'm not sure what you're saying here.



In our API, the attributes of a property affect JS access, but not C++
access. E.g. if a property is ReadOnly, it can't be changed from JS,  
but

can still be changed from C++. Same thing with DontDelete.


A C++ object can expose a binding to JS where DontDelete or Readonly  
properties may disappear or change (the JSC API allows this) -- but  
don't let your C++ API delete non-deletable JS properties, it's  
unnecessary and would be a willful violation of the spec for no  
reason.  The ES5 spec says quite explicitly that a property that is  
marked as DontDelete may not be removed -- adding an API that both  
requires changes to JSC for non-compatibility reasons, that in turn  
require a violation of the spec is bogus.



The debugger is not API, and should not be depended upon.  If you are

interacting with the debugger you are not using the JSC API, and so
you will not be able to rely on JSC not changing and breaking your  
API.




That's perfectly understandable, and it's something we (as in "not  
you")

have to live with for the time being.


And when you want to continue to support your API in future and we rip  
out the current model entirely? then what?  JSC does not have an API  
to allow debugging, you should just live with this for the time being  
rather than trying to expose a fairly broken model using non-API  
functions.


--Oliver

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

Re: [webkit-dev] Qtish API for JavaScriptCore

[Kent Hansen]

Hi Oliver,

ext Oliver Hunt wrote:
> I am concerned about the performance impact of changing  
> getPropertyNames, as well as correctness -- getPropertyNames does  
> specifically exist for the support of for..in enumeration.
>   

Any concerns about adding a separate function for that, then (i.e.
getNonEnumerablePropertyNames())? JSC would not use that function
itself, it would just give us a chance to introspect JS objects and our
own host objects. Of course, it'd mean keeping that function working
whenever there's e.g. a refactoring/restructuring of
JSObject::getPropertyNames() (only once every full moon, right? :-) ).

>   
>> - Being able to delete a property from C++ even if the property has
>> DontDelete=true. We implemented this by adding a checkDelete  
>> argument to
>> JSObject::deleteProperty(). I think it's similar in spirit to the put 
>> ()
>> methods that have a checkReadOnly argument. The patch is not that  
>> large
>> compared to the getPropertyNames() change, because there aren't as  
>> many
>> classes reimplementing deleteProperty().
>> 
>
> I'm not sure what you're saying here.
>   

In our API, the attributes of a property affect JS access, but not C++
access. E.g. if a property is ReadOnly, it can't be changed from JS, but
can still be changed from C++. Same thing with DontDelete.


>   
>> - Storing CallFrame::callee() as a generic JSObject instead of a
>> JSFunction. Any JSObject can be invoked as long as its getCallData()
>> returns something, so we didn't see a good reason for only being  
>> able to
>> store JS callees (in the QtScript API we need to offer the callee for
>> native functions as well).
>> 
> I'd be very careful with a change like this.  Especially given the  
> inspector debugger is already able to do what you're claiming you  
> needed to change JSC to support.
>   

OK. We'll take a look at the Inspector and see if we can do what it
does. The change just made it possible to streamline our code, that's all.

> The debugger is not API, and should not be depended upon.  If you are  
> interacting with the debugger you are not using the JSC API, and so  
> you will not be able to rely on JSC not changing and breaking your API.
>   

That's perfectly understandable, and it's something we (as in "not you")
have to live with for the time being.


> These really should already be in bugs.webkit.org, as i've said i'm  
> kind of concerned about some of the changes you've described so it  
> would have helped you to talk to us earlier.
>   

Thanks for the concern, but please don't lose any sleep due to us. :-)
We're not out to "lock down" JSC due to our own API requirements.
FWIW, for the most part, layering our API on top of JSC has been
straightforward. Can't all be sunshine, of course.

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

Re: [webkit-dev] Qtish API for JavaScriptCore

[Oliver Hunt]

On Aug 28, 2009, at 3:25 AM, Kent Hansen wrote:


ext Simon Hausmann wrote:

Hi Oliver,

On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:


A further
issue is that any API that binds directly to JSC internals
realistically needs to be developed by the engineers working on the
core engine as a developing such an API needs enormous care to not
cause harmful long term problems.



I understand that. We've been bitten by that, too, as we've ported  
our
existing API to JSC internals, to see how it can be done. The vast  
majority
was straight forward as we've been careful in the original design  
to only
expose what you can do in JavaScript itself. In a few places we've  
made
mistakes but we've found solutions for them, too, that don't affect  
the
internals in flexibility or performance. (*pokes some of the guys  
to elaborate

a bit here*)




Hi,
Here's a rough overview of JSC hacking we've been doing:

- Fixing purely ECMA-compliance-related things. These are mostly small
discrepancies we've found when running our tests; the associated JSC
patches should be straightforward to either accept or reject (we'll be
creating separate Bugzilla tasks for these). If they're not fixed,  
it's

not critical for us, as I doubt much real-world JS depends on the
behavior anyway (otherwise you'd think the issues would have been  
fixed

already).


Fixing ES compliance is unrelated to the QT JS API, but such patches  
also need to be fairly carefully examined, as there are places where  
our behaviour differs from some other engines but is in compliance  
with the spec.  Other changes may result in site breakages, etc.  They  
should really just be placed on bugs.webkit.org for review.




- Adding ability to introspect non-enumerable properties of objects  
from

C++. JSObject::getPropertyNames() seems to be made only to support the
JS for..in statement; we added an extra parameter so you could ask for
non-enumerable properties as well. We need this for debugging and
autocompletion. The patch is large because there are a lot of classes
that reimplement getPropertyNames(), so all the signatures must be
updated... I'm interested in hearing if there are alternatives, e.g.
adding a separate virtual function getNonEnumerablePropertyNames() and
only implement it in JSObject for a start (and we would then  
reimplement

it in our own Qt "bridge" classes).
See also https://bugs.webkit.org/show_bug.cgi?id=19119; looks like the
Inspector would also gain from providing this functionality.


I am concerned about the performance impact of changing  
getPropertyNames, as well as correctness -- getPropertyNames does  
specifically exist for the support of for..in enumeration.




- Being able to delete a property from C++ even if the property has
DontDelete=true. We implemented this by adding a checkDelete  
argument to
JSObject::deleteProperty(). I think it's similar in spirit to the put 
()
methods that have a checkReadOnly argument. The patch is not that  
large
compared to the getPropertyNames() change, because there aren't as  
many

classes reimplementing deleteProperty().


I'm not sure what you're saying here.



- Storing CallFrame::callee() as a generic JSObject instead of a
JSFunction. Any JSObject can be invoked as long as its getCallData()
returns something, so we didn't see a good reason for only being  
able to

store JS callees (in the QtScript API we need to offer the callee for
native functions as well).
I'd be very careful with a change like this.  Especially given the  
inspector debugger is already able to do what you're claiming you  
needed to change JSC to support.



- Some more flexibility in dealing with timeouts: Make TimeoutChecker
subclassable so we can get a callback at timeout, make it possible to
adjust the timeout interval.

Once again, i'd need to see the patch and perf impact.


- Adding column number information to the parser + debugger callback.
Not life-critical, but reasonably easy to add to the parser anyway.
The parser already includes sufficient information for this.  Tracking  
such extra information again is highly likely to regress parsing  
performance so i'd need confirmation of performance -- but as i said,  
it's unnecessary to modify the parser for this.


- Hacking error.sourceURL and error.line to be called error.fileName  
and
error.lineNumber instead. We don't know how many existing QtScript  
users

out there rely on the fileName and lineNumber properties being present
on error objects, though; maybe we can make the source-incompatible
change JS-wise of using the JSC names. A safer solution would be to  
just
copy sourceURL and line over to fileName and lineNumber in the parts  
of
our code where we have the chance to do that (i.e. not inside JSC  
itself).
You can't change these names, and we don't really want additional  
properties added to exception objects.  Fixing the way such  
information is propagated is a long term goal.



- Trying to make our debugger 

Re: [webkit-dev] [webkit]Incrementing problem in css

[Simon Fraser]

On Sep 1, 2009, at 6:13 AM, hodovan.ren...@stud.u-szeged.hu wrote:


Hi All!

Running some LaoutTests I found the following:
There is an increment object in css. If the children of this object  
was modified (append or remove), then the rest of the list wasn't  
adapt to this.
E.g.: append to 1-2-3-4 one more element at position 2 the result  
is: 1-2-2-3-4.
remove from the same the second element: 1-3-4. Testing it in  
firefox and opera the results are 1-2-3-4 and 1-2-3. Unfortunatly  
Safari (on Windows) doesn't adapt as well. I feel this dynamic  
adaptation has not yet implemented, am I rigth?
If so I would try to implement it myself. Any help or suggestion to  
do this is welcome.


You should look for an existing bugzilla bug on this issue, and if  
there isn't one, file a new bug with a simple testcase. Then feel free  
to start working on it.


Simon

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

Re: [webkit-dev] New marking model for GC collected objects

[Zoltan Herczeg]

Hi Oliver,

it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date
object is sometimes freed by the garbage collector.

More specifically:
The double (millisecond) representation of a date object (returned by a
"new Date" expression) is stored in JSWrapperObject: m_internalValue. This
m_internalValue points to a JSNumberCell, which stores the double value.
Although this JSNumberCell is referenced by m_internalValue, the GC still
collects its memory space.

How can I fix this bug with the new mark() model?

Zoltan

> Last night I landed a patch that replaces the old recursive marking
> functions with a new iterative model that uses an explicit mark
> stack.  This means that any custom mark methods that you need to write
> now need to be slightly different from what they were previously, i'll
> attempt to summarise here.
>
> The most obvious change is that an object is no longer responsible for
> marking itself instead the recursive mark methods have been replaced
> by a new virtual markChildren(MarkStack&) which is responsible for
> appending an objects children to the stack.
>
> The MarkStack is a very simple class, and the only method you really
> need to know about is MarkStack::append which adds a new object to the
> stack.
>
> The changes to how your custom marking functions are implemented are
> trivial, but here's a simple example
> void MyAwesomeObject::mark()
> {
>  Base::mark();
>  if (!m_child.marked())
>  m_child.mark();
> }
>
> Becomes
> void MyAwesomeObject::markChildren(MarkStack& markStack)
> {
>  Base::markChildren(markStack);
>  markStack.append(m_child);
> }
>
> And that's it, you're done.
>
> It's important to note that you will never be in a position where you
> call markChildren yourself, if you are that is an error.
>
> --Oliver
>
> ___
> 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] [webkit]Incrementing problem in css

[Hodovan . Renata]

Hi All!

Running some LaoutTests I found the following:
There is an increment object in css. If the children of this object  
was modified (append or remove), then the rest of the list wasn't  
adapt to this.
E.g.: append to 1-2-3-4 one more element at position 2 the result is:  
1-2-2-3-4.
remove from the same the second element: 1-3-4. Testing it in firefox  
and opera the results are 1-2-3-4 and 1-2-3. Unfortunatly Safari (on  
Windows) doesn't adapt as well. I feel this dynamic adaptation has not  
yet implemented, am I rigth?
If so I would try to implement it myself. Any help or suggestion to do  
this is welcome.


Thanks in Advance.
Renata Hodovan


This message was sent using IMP, the Internet Messaging Program.

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

Re: [webkit-dev] [webkit-changes] [47915] trunk

[Adam Roben]

On Aug 31, 2009, at 7:44 PM, bweinst...@apple.com wrote:


+if (m_renderer->isTextArea())
+return static_cast(m_renderer->node())- 
>readOnly();


This doesn't look right. I think we should be casting to  
HTMLTextAreaElement. A  in the test case might have caught  
this.


-Adam

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

Re: [webkit-dev] GlobalScript API.

[Patrick Mueller]

Dmitry Titov wrote:


I'd appreciate much your advice on the whole API and on the way to bring it
into WebKit.


I'm very interested in this, perhaps mainly as the first method 
available in the browser/JavaScript space to be able to create new contexts.




Here is an actual API:
---
Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler,
errorHandler);


I've mentioned before that this API turns out to be very similiar to the 
serverJS notion of a "module".


https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

Differences are the name: require -> webkitGlobalScript; semantics about 
sharing across pages (not relevant to the serverJS work); the "exports" 
variable in the module which provides the reference to the globalScript 
return value the client sees; and that this is async vs. serverJS's sync 
model.


Of most interest is the notion of the "exports" variable.  Instead of 
exposing the "global" scope of the global script itself as the return 
value, you actually have to assign something to the exports variable 
from within the global script for it to be available in the caller.  The 
nice thing about this is that it provides a nice way to create private 
references within your global script.


It would probably be useful for folks to at least look at some of the 
work going on in the serverJS world - actually, just remembered they 
have changed their name to CommonJS.  The narwhal work probably provides 
a good concrete example of what they're doing (it's been a few months 
since I looked at it in depth).


   http://github.com/tlrobinson/narwhal/tree/master

I'm not a big fan of stringing fairly arbitrary parameters together as 
the handlers seem to be in the webkitGlobalScript() function, especially 
since it's pretty simple to send extendable objects instead.  Would 
prefer to see something like:


new webkitGlobalScript("foo", "foo.js", {
   loadHandler: function(something) {},
   errorHandler: function(something) {}
});


API exposed to Global Script (on its global scope object)
- Timers
- XHR
- Navigator
- localStorage
- Database
- Workers


Previously mentioned was a way to load an additional script from within 
the global script.  Does the Workers API to do that handle this?  That's 
a sync API, right?  Is that what we want?


--
Patrick Mueller - http://muellerware.org

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

Re: [webkit-dev] Leak Bot

[Mark Rowe]

On 2009-09-01, at 04:26, Eric Seidel wrote:

It seems we have a leak bot again!  Thanks to all who made that  
possible!


There seem to be a bunch of leaks though.  They all seem CFNetwork  
related:

http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r47923%20(318)/

I'm not sure if that's because we're leaking in WebCore and it's  
just showing up as CFNetwork structs, or if it's just DumpRenderTree  
isn't telling the network layer to clean up after itself properly,  
or if CFNetwork is actually leaking...


I'm curious if someone has done investigation into the reported leaks?


I had been investigating this when I have time.   There are clearly  
many CFNetwork objects being leaked, but there are also a number of  
WebCore datatypes being leaked as well (StringImpl's being the first  
that I noticed), but the object graph involved is quite hairy so it's  
hard to pin down which object is the root of the leak.  Based on the  
pattern of data in the leaks output I suspect there are likely to be a  
number of distinct leaks.  I plan to dig in to these some more later  
this week.


- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Leak Bot

[Eric Seidel]

It seems we have a leak bot again!  Thanks to all who made that possible!

There seem to be a bunch of leaks though.  They all seem CFNetwork related:
http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r47923%20(318)/

I'm not sure if that's because we're leaking in WebCore and it's just
showing up as CFNetwork structs, or if it's just DumpRenderTree isn't
telling the network layer to clean up after itself properly, or if CFNetwork
is actually leaking...

I'm curious if someone has done investigation into the reported leaks?

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

Re: [webkit-dev] Qtish API for JavaScriptCore

[Kent Hansen]

ext Simon Hausmann wrote:
> Hi Oliver,
>
> On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:
>   
>> A further
>> issue is that any API that binds directly to JSC internals
>> realistically needs to be developed by the engineers working on the
>> core engine as a developing such an API needs enormous care to not
>> cause harmful long term problems.
>> 
>
> I understand that. We've been bitten by that, too, as we've ported our 
> existing API to JSC internals, to see how it can be done. The vast majority 
> was straight forward as we've been careful in the original design to only 
> expose what you can do in JavaScript itself. In a few places we've made 
> mistakes but we've found solutions for them, too, that don't affect the 
> internals in flexibility or performance. (*pokes some of the guys to 
> elaborate 
> a bit here*)
>   


Hi,
Here's a rough overview of JSC hacking we've been doing:

- Fixing purely ECMA-compliance-related things. These are mostly small
discrepancies we've found when running our tests; the associated JSC
patches should be straightforward to either accept or reject (we'll be
creating separate Bugzilla tasks for these). If they're not fixed, it's
not critical for us, as I doubt much real-world JS depends on the
behavior anyway (otherwise you'd think the issues would have been fixed
already).

- Adding ability to introspect non-enumerable properties of objects from
C++. JSObject::getPropertyNames() seems to be made only to support the
JS for..in statement; we added an extra parameter so you could ask for
non-enumerable properties as well. We need this for debugging and
autocompletion. The patch is large because there are a lot of classes
that reimplement getPropertyNames(), so all the signatures must be
updated... I'm interested in hearing if there are alternatives, e.g.
adding a separate virtual function getNonEnumerablePropertyNames() and
only implement it in JSObject for a start (and we would then reimplement
it in our own Qt "bridge" classes).
See also https://bugs.webkit.org/show_bug.cgi?id=19119; looks like the
Inspector would also gain from providing this functionality.

- Being able to delete a property from C++ even if the property has
DontDelete=true. We implemented this by adding a checkDelete argument to
JSObject::deleteProperty(). I think it's similar in spirit to the put()
methods that have a checkReadOnly argument. The patch is not that large
compared to the getPropertyNames() change, because there aren't as many
classes reimplementing deleteProperty().

- Storing CallFrame::callee() as a generic JSObject instead of a
JSFunction. Any JSObject can be invoked as long as its getCallData()
returns something, so we didn't see a good reason for only being able to
store JS callees (in the QtScript API we need to offer the callee for
native functions as well).

- Some more flexibility in dealing with timeouts: Make TimeoutChecker
subclassable so we can get a callback at timeout, make it possible to
adjust the timeout interval.

- Adding column number information to the parser + debugger callback.
Not life-critical, but reasonably easy to add to the parser anyway.

- Hacking error.sourceURL and error.line to be called error.fileName and
error.lineNumber instead. We don't know how many existing QtScript users
out there rely on the fileName and lineNumber properties being present
on error objects, though; maybe we can make the source-incompatible
change JS-wise of using the JSC names. A safer solution would be to just
copy sourceURL and line over to fileName and lineNumber in the parts of
our code where we have the chance to do that (i.e. not inside JSC itself).

- Trying to make our debugger callbacks (which we relay from the JSC
debugger callbacks) have precisely the same semantics as in our old
engine. We have a similar debugging interface as JSC::Debugger, but
obviously "similar" doesn't cut it for this low-level stuff. Geoffrey
Garen said in another mail in this thread that the debugger exposed too
much internal engine knowledge, and that's also true for the API we
provide for QtScript.

We'll be creating Bugzilla tasks with patches for the things we hope
make sense to get upstream (regardless of whether the QtScript API
itself makes it upstream at some point, which I agree is not very
reasonable so long as it depends on JSC internals), so we can discuss
any implications in more detail.

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