Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 22, 2009, at 10:07 PM, Adam Barth wrote: On Mon, Jun 22, 2009 at 9:58 PM, Peter Kastingpkast...@google.com wrote: On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth aba...@webkit.org wrote: On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com wrote: Your proposed alternative will have different behavior. It will use the lexical global object of the calling JavaScript function, instead of the global object originally associated with the Options constructor. Yes. Almost everywhere you see this pattern it's incorrect. We have this bug a lot. To be clear, are you saying the original pattern, or the simpler one Drew proposes is typically the incorrect one? (I assume the latter.) The latter one. The V8 binding are better about this because we have v8::Context::GetCurrent(), which often gives you the context the JSC bindings have to manually manage. I suspect most JS bindings in WebKit use the original more complicated pattern Drew cited, instead of the more succinct but incorrect one. Here's how the two bindings relate (if you look at both bindings and wonder): v8::Context::GetEntered() ~~ exec-dynamicGlobalObject() v8::Context::GetCalling() ~~ exec-lexicalGlobalObject() v8::Context::GetCurrent() ~~ It might be good to add a similar GetCurrent concept to JSC (although, hopefully with a better name) so we can remove all this manual, error-prone caching / mark()ing. What does the current context correspond to? How is it retrieved? Guessing wildly based on the names, I'm assuming host functions in v8 have the equivalent of their own scope chain and thus in some sense their own lexical global object. We could do that for JSC, except that for most things it would be useless - it's only potentially useful for DOM-level explicit constructors, since JS-level ones are supposed to use the calling function's lexical global object as the basis for everything, and most other host functions don't need it at all. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] knowing filesize without downloding ... possible ?
Hi all, Is there any way in QT to know file size before downloading the actual file.(by just URL) ? If I use wget on console, it first prints file size before it starts downloading. I am using all QNetwork* classes for download. regards Purush ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] knowing filesize without downloding ... possible ?
Purushottam Sholapur wrote at: 2009. 06. 23. 08.32.: Hi all, Is there any way in QT to know file size before downloading the actual file.(by just URL) ? If I use wget on console, it first prints file size before it starts downloading. I am using all QNetwork* classes for download. regards Purush Hi Purush, if the server supports it this is possible through class ResourceResponse's expectedContentLength() method. Let's see: WebCore/platform/network/ResourceResponseBase.h WebCore/platform/network/qt/ResourceResponse.h Example for ResourceResponse's usage: WebCore/platform/network/qt/QNetworkReplyHandler.cpp Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Mon, Jun 22, 2009 at 11:07 PM, Maciej Stachowiakm...@apple.com wrote: I suspect most JS bindings in WebKit use the original more complicated pattern Drew cited, instead of the more succinct but incorrect one. There are some bugs on file about this. I've been meaning to go through and look at all these cases. Here's how the two bindings relate (if you look at both bindings and wonder): v8::Context::GetEntered() ~~ exec-dynamicGlobalObject() v8::Context::GetCalling() ~~ exec-lexicalGlobalObject() v8::Context::GetCurrent() ~~ It might be good to add a similar GetCurrent concept to JSC (although, hopefully with a better name) so we can remove all this manual, error-prone caching / mark()ing. What does the current context correspond to? It's the context in which the method was defined. For DOM methods, V8 treats them as being defined by the context of their owner document. How is it retrieved? No idea. I think what happens is you enter the context for a particular frame before constructing all the objects / methods for that frame. Then the DOM methods just have a scope like regular JavaScript methods. Guessing wildly based on the names, I'm assuming host functions in v8 have the equivalent of their own scope chain and thus in some sense their own lexical global object. I'm not an expert on this, but this fits my mental model. In general, V8 tries to implement DOM objects as close to how user-defined objects would be implemented as possible. We could do that for JSC, except that for most things it would be useless - it's only potentially useful for DOM-level explicit constructors, since JS-level ones are supposed to use the calling function's lexical global object as the basis for everything, and most other host functions don't need it at all. That's possible. I don't have a good idea of what it costs to provide. The benefit is it makes it easier to write correct bindings code. (Or maybe it makes it harder because you have more contexts to choose from and choosing the right context is subtle.) I don't really know how to solve this problem except by writing tests. However, tests don't really help when introducing new kinds of objects (e.g., workers, database transactions). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Javascript window.open()
Hi, Look at the allowPopUp() function in bindings/js/JSDOMWindowBase.cpp You can disable window.open() in settings. Check the Settings::setJavaScriptCanOpenWindowsAutomatically. If you are using QT, you can do it with QWebSettings. Regards, Kwang Yul Seo On Thu, Jun 18, 2009 at 1:45 AM, Zongheng Zhouzongheng.z...@gmail.com wrote: Hi, I am using the QT port of webkit. Instead of doing anything else for the Javascript 's window.open(), I only want to log the URL being requested. Can anybody tell me how I can change the behavior of the window.open? Thanks, ___ 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] Question about Constructors in WebKit JS Bindings
On Jun 22, 2009, at 11:58 PM, Adam Barth wrote: That's possible. I don't have a good idea of what it costs to provide. The benefit is it makes it easier to write correct bindings code. (Or maybe it makes it harder because you have more contexts to choose from and choosing the right context is subtle.) I don't really know how to solve this problem except by writing tests. However, tests don't really help when introducing new kinds of objects (e.g., workers, database transactions). It would be great to make it easier to write DOM constructors correctly. Perhaps documenting the pattern and/or introducing a common base class will work. I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. What I'm dubious of is whether we should store extra data on every DOM object (of which there are hundreds) to make it easier to write DOM constructors (of which there are 9). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 23, 2009, at 10:41 AM, Maciej Stachowiak wrote: On Jun 22, 2009, at 11:58 PM, Adam Barth wrote: I don't really know how to solve this problem except by writing tests. However, tests don't really help when introducing new kinds of objects (e.g., workers, database transactions). Perhaps it's possible to write a test that both checks which global object is used for every constructor, and checks that the test covers all constructors at the same time. Maybe there is a practical way to iterate the constructors, as long as we create an exception list of objects that look like constructors but are not. Tests are the bests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 10:41 AM, Maciej Stachowiakm...@apple.com wrote: On Jun 22, 2009, at 11:58 PM, Adam Barth wrote: It would be great to make it easier to write DOM constructors correctly. Perhaps documenting the pattern and/or introducing a common base class will work. A common base class sounds like a good idea. I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. What I'm dubious of is whether we should store extra data on every DOM object (of which there are hundreds) to make it easier to write DOM constructors (of which there are 9). No argument here. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 10:44 AM, Darin Adlerda...@apple.com wrote: Perhaps it's possible to write a test that both checks which global object is used for every constructor, and checks that the test covers all constructors at the same time. Maybe there is a practical way to iterate the constructors, as long as we create an exception list of objects that look like constructors but are not. Tests are the bests. I'd be happy to write this test. Is there a good way to tell if something is a constructor versus a function? I guess we can try calling all the global functions as constructors and see what happens. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 23, 2009, at 11:50 AM, Adam Barth wrote: Is there a good way to tell if something is a constructor versus a function? Leading capital letter may be a good rule to start with. I don't think we have plans to add functions that start with a capital letter or constructors that do not. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how do i know that i'm clicking on a flash movie?
hi guys,
i want to make a correction on my previous message. i've just tried another
online video site, it turned out that the webview does respond to flash
click. but youtube is different. and i guess i should not post the message
here, it seems to be a QT question.
On Tue, Jun 23, 2009 at 1:24 PM, Shi Yan billco...@gmail.com wrote:
hello guys,
i'm trying to implement a feature with the Qt webkit such that when
the user clicks on a web page, i can know the corresponding html tag
that he/she is clicking. for example, if the user clicks an image, i
should be able to get img tag and also the src attribute.
i modified the hitTestContent function in this way:
QWebHitTestResult QWebFrame::hitTestContent(const QPoint pos) const
{
if (!d-frame-view() || !d-frame-contentRenderer())
return QWebHitTestResult();
HitTestResult result =
d-frame-eventHandler()-hitTestResultAtPoint(d-frame-view()-windowToContents(pos),
/*allowShadowContent*/ false);
printf(Inner Node Type:%d;\n,result.innerNode()-nodeType());
std::coutnode value:(result.innerNode()-nodeValue().operator
QString()).toStdString()std::endl;
if(result.innerNode()-nodeType()==Node::ELEMENT_NODE)
{
Element* oldElement =
static_castElement*(result.innerNode());
std::cout(oldElement-tagName().operator
QString()).toStdString()std::endl;
}
else if(result.innerNode()-nodeType()==Node::TEXT_NODE)
{
printf(text node!\n);
}
return QWebHitTestResult(new QWebHitTestResultPrivate(result));
}
this code works for text nodes and element nodes. but when i click on
a piece of flash movie, such as a youtube movie, the hitTestContent
isn't called. i don't know can i get the flash information by
clicking. thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
Following up after an IRC chat with Ian - for Workers it is his intention to always grab the context from the currently executing script, not from the window the constructor originated from. So for Workers, using the more succinct implementation is actually correct - in his words all Worker constructors are created equal. -atw On Tue, Jun 23, 2009 at 2:20 PM, Drew Wilson atwil...@google.com wrote: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
BTW, Adam - can you elaborate your specific concerns? On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson atwil...@google.com wrote: Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 23, 2009, at 3:37 PM, Drew Wilson wrote: Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. window.Worker.prototype should be the initial value of new Worker().__proto__ (or equivalently, of the internal [[Prototype]] property). This should be taken from the constructor object actually used, I think, but there is no reason to store a global object or document reference to achieve this effect. - Maciej -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
I don't mean to pick on workers specifically. We have lots of bugs in the bindings where we attach the __proto__ property of new objects to the wrong prototype chain. My specific concern is that we should fix these bugs. :) Adam On Tue, Jun 23, 2009 at 3:38 PM, Drew Wilsonatwil...@google.com wrote: BTW, Adam - can you elaborate your specific concerns? On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson atwil...@google.com wrote: Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 23, 2009, at 3:44 PM, Adam Barth wrote: I don't mean to pick on workers specifically. We have lots of bugs in the bindings where we attach the __proto__ property of new objects to the wrong prototype chain. My specific concern is that we should fix these bugs. :) Tentatively speaking, I think it's always right to attach to the prototype chain from the constructor object actually used (i.e. the one present in its prototype property). Any time we don't do that, I believe it is a bug. (I'm qualifying all my statements because this area is complex enough that I'm unsure whether there are exceptions.) - Maciej Adam On Tue, Jun 23, 2009 at 3:38 PM, Drew Wilsonatwil...@google.com wrote: BTW, Adam - can you elaborate your specific concerns? On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson atwil...@google.com wrote: Not sure. There's language in the WebIDL spec around prototype objects of interface objects, but I'm not sure how window.Worker.prototype is intended to relate to new Worker().prototype (if at all), based on my 10 minutes of scanning specs. -atw On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth aba...@webkit.org wrote: 2009/6/23 Drew Wilson atwil...@google.com: On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote: I am not even sure all of these should have the same behavior, however. For instance, as I read the Web Workers spec, the lexical global object may be correct thing to use for the Worker constructor. I looked at the spec briefly. What leads you to think that? It's probably a bug in the spec. Section 4.5 of the web workers spec reads: Given a script's global scope o when creating or obtaining a worker, the list of relevant Document objects to add depends on the type of o. If o is a WorkerGlobalScope object (i.e. if we are creating a nested worker), then the relevant Documents are the Documents that are in o's own list of the worker's Documents. Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. So it seems to imply that parent document for a worker is derived from the currently executing script's global scope. I'll ping IanH about this - it may not be what he intended. There's another question, which is where does the prototype chain of the JS object you get out of the worker constructor point? It might not have anything to do with this Document calculation. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Jun 23, 2009, at 4:08 PM, Drew Wilson wrote:
Oh, certainly - I just started looking at the Worker constructor
code, so I definitely have no sense of ownership there, so pick
away. I was just trying to understand the issues well enough to
understand what the Worker code is doing before I steal it :)
Looking at the Workers code (since that happens to be where I'm
poking around):
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
: DOMObject(JSWorkerConstructor::createStructure(exec-
lexicalGlobalObject()-objectPrototype()))
{
putDirect(exec-propertyNames().prototype,
JSWorkerPrototype::self(exec, exec-lexicalGlobalObject()), None);
putDirect(exec-propertyNames().length, jsNumber(exec, 1),
ReadOnly|DontDelete|DontEnum);
}
It looks like the constructor's .prototype is taken from the
originating window (set at the time the constructor itself is
created) - I haven't followed the construction code, but I'm
guessing that results in the prototype property of new objects being
attached to the chain from the original window. Is that incorrect
behavior?
The code above means that Worker.prototype is set at the time the
Worker constructor itself is created, which is good. In the line you
bolded, a fresh prototype object is created, and under the covers it
will get cached. However, it looks to me like the Worker wrapper will
use the prototype from the Window where the reference is created,
rather than the one that the Worker constructor came from. So
everything I said may be wrong. Short version: this all needs tests.
Also, there might be a subtle bug in the above code: what if
window.Worker is first accessed from a different frame? Then the
prototype of the Worker constructor itself will use the other frame's
Object prototype as its prototype. I'm not sure if that is right. I
think maybe JSWorkerConstructor should be passed the global object
from which it is retrieved as a property, instead of using the lexical
global object.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com wrote: The code above means that Worker.prototype is set at the time the Worker constructor itself is created, which is good. In the line you bolded, a fresh prototype object is created, and under the covers it will get cached. However, it looks to me like the Worker wrapper will use the prototype from the Window where the reference is created, rather than the one that the Worker constructor came from. So everything I said may be wrong. Short version: this all needs tests. Agreed, tests would be good. BTW, I don't see where the code is using the prototype from the Window where the reference is created. I do see where the current ScriptExecutionContext is passed in to the Worker() constructor, but that's just the WebCore class and shouldn't affect the JSWorker prototype? Also, there might be a subtle bug in the above code: what if window.Worker is first accessed from a different frame? Then the prototype of the Worker constructor itself will use the other frame's Object prototype as its prototype. I'm not sure if that is right. I think maybe JSWorkerConstructor should be passed the global object from which it is retrieved as a property, instead of using the lexical global object. Good catch. This bug seems to be in all our custom generated constructors. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Constructors in WebKit JS Bindings
[+sam] On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilsonatwil...@google.com wrote: On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com wrote: Also, there might be a subtle bug in the above code: what if window.Worker is first accessed from a different frame? Then the prototype of the Worker constructor itself will use the other frame's Object prototype as its prototype. I'm not sure if that is right. I think maybe JSWorkerConstructor should be passed the global object from which it is retrieved as a property, instead of using the lexical global object. Good catch. This bug seems to be in all our custom generated constructors. Yes. This has caused us headaches (e.g., security bugs) in the past. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New WebKit port to Haiku
Hello all, As part of the Google Summer of Code I am mentoring a student named Maxime Simon, who is resurrecting and continuing my port of WebKit to the Haiku operating system (http://haiku-os.org). I originally did this port in 2007, but stopped working on it until now. Obviously I never had it committed to the WebKit tree. As part of the GSoC project Maxime has recently updated my port and got it building with the latest WebKit code (surprisingly it did not take too long.) He created a bug (https://bugs.webkit.org/show_bug.cgi?id=26620) to add this code to the WebKit repo. In his comments on that bug Eric Seidel asked that an email be sent here introducing ourselves. I figured I would start and let Maxime respond to this email if he wants. To assuage Eric's concerns, Haiku will not be disappearing anytime soon. The project has existed since 2001 and moves forward everyday (though progress can be slow since we have a small team and a big project: the recreation and continuation of the BeOS.) A huge part of any modern operating system is a good web browser and while Haiku has a port of Firefox, it does not have the speed and feel we want. Since WebKit is fast, elegant and easy to port it was the ideal choice for the engine behind our new web browser. So it would be really great if our port could become an official one in the WebKit tree :) I sure hope that Maxime will stick around after the Summer of Code, but in case he does not I will be sure to keep the Haiku WebKit port updated. I think the people who ported Firefox to BeOS and then Haiku will also want to help on this project. Since I plan to use Haiku as my main OS and the WebKit browser as my main browser I will truly be eating my own dogfood and it will be in my interest to keep it updated and working well :) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we restrict Web Fonts to same-origin by default?
On Mon, Jun 22, 2009 at 1:26 PM, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 22, 2009 at 12:45 PM, David Hyatt hy...@apple.com wrote: On Jun 22, 2009, at 2:38 PM, Maciej Stachowiak wrote: Mozilla restricts downloaded fonts to same-origin by default, with the ability for the hosting site to open up access via Access-Control (aka CORS). Apparently this step has the potential to make font foundries more comfortable about using straight up OpenType fonts on the Web, without introducing DRM. Should we follow Mozilla's lead on this? I see no reason to do this. I also see harm from doing this. There are many sites (e.g. Google Docs) that serve static content of a different, cookie-less domain for performance reasons. They would be unable to do this for Web Fonts with this restriction. This is an increasingly common practice as tools like http://code.google.com/speed/page-speed/ become more ubiquitous. Ojan Wouldn't Access-Control still support serving the Web Fonts off of a secondary domain? -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we restrict Web Fonts to same-origin by default?
On Jun 23, 2009, at 8:47 PM, Darin Fisher wrote: On Mon, Jun 22, 2009 at 1:26 PM, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 22, 2009 at 12:45 PM, David Hyatt hy...@apple.com wrote: On Jun 22, 2009, at 2:38 PM, Maciej Stachowiak wrote: Mozilla restricts downloaded fonts to same-origin by default, with the ability for the hosting site to open up access via Access- Control (aka CORS). Apparently this step has the potential to make font foundries more comfortable about using straight up OpenType fonts on the Web, without introducing DRM. Should we follow Mozilla's lead on this? I see no reason to do this. I also see harm from doing this. There are many sites (e.g. Google Docs) that serve static content of a different, cookie-less domain for performance reasons. They would be unable to do this for Web Fonts with this restriction. This is an increasingly common practice as tools like http://code.google.com/speed/page-speed/ become more ubiquitous. Ojan Wouldn't Access-Control still support serving the Web Fonts off of a secondary domain? The main effect would be to change the default behavior. Hotlinking would be disabled unless the server opts in via Access-Control. The Mozilla folks haven't made a hugely compelling case for this restriction though. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore in Windows Applications
Hi Eric, Let me try to answer your last few questions in order. Unfortunately, I'm on vacation this week and don't have my Windows machine available, otherwise I would have tried to get you the DLLs you asked for. 1. You *should* be able to mix/match the CFLite.lib and DLL from the CallJS example and the files in the Release and Debug WebKit zipfiles on my iDisk. I generated them at the same time (or around the same day) trying to get them in sync, so they should be compatible. 2. The build errors you are seeing are because there are a few things missing from the WebKit SVN repository. These are packaged up in a ever-shrinking patch attached to https://bugs.webkit.org/show_bug.cgi?id=17484 . Currently it patches the WebView.cpp file to exclude some printing logic that I have not ported to Cairo yet, and it modifies the WebCore/ config.h file to instruct the Windows build includes to use the Cairo/ cURL support, rather than the CG/CFNetwork stuff. 3. The following error looks like it's building the Debug target, rather than the Debug_Cairo target, as the FrameCGWin.cpp file is not part of the files in the Cairo build manifest (and neither are the CFNetwork-based files): FrameCGWin.cpp ..\page\win\FrameCGWin.cpp(69) : error C2664: 'WebCore::GraphicsContext::GraphicsContext(PlatformGraphicsContext *)' : cannot convert parameter 1 from 'CGContextRef' to 'PlatformGraphicsContext *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast FrameWin.cpp PageWin.cpp [...] ResourceLoaderCFNet.cpp ..\loader\cf\ResourceLoaderCFNet.cpp(34) : error C2039: 'shouldCacheResponse' : is not a member of 'WebCore::ResourceLoader' c:\cygwin\home\ericbrunstad\WebKit\WebCore\loader \ResourceLoader.h(50) : see declaration of 'WebCore::ResourceLoader' I unfortunately don't have a license for Windows to run on my laptop (MacBookPro), so I am somewhat limited in what I can do remotely at the moment. Please make sure you are selecting the Debug_Cairo or Release_Cairo build target in Visual Studio, or that you are building with the command line flag --cairo-win32 if you are using buid-webkit. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
