[webkit-dev] Compiling on Tiger and running the binary on Leopard causes vm_map() to fail
Hi, JavaScriptCore uses some compile-time defines to decide which flags to pass to vm_map() and mmap(), depending on the Mac OS version. Now, if WebKit is built and run on the same version, that's obviously fine, but we've found that if we build on Tiger but run on Leopard, the vm_map() call fails. Similarly, mmap() fails if we build on Leopard but run on Tiger. This case can be made to work by defining BUILDING_ON_TIGER even when building on Leopard, but that doesn't feel too good... Can/should the decision of which flags to pass be made at runtime instead? Regards, Kent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling on Tiger and running the binary on Leopard causes vm_map() to fail
On Sep 10, 2009, at 9:04 AM, Kent Hansen wrote: JavaScriptCore uses some compile-time defines to decide which flags to pass to vm_map() and mmap(), depending on the Mac OS version. Now, if WebKit is built and run on the same version, that's obviously fine, but we've found that if we build on Tiger but run on Leopard, the vm_map() call fails. That's right. There are many places where WebKit makes compile time assumptions about Tiger vs. Leopard vs. Snow Leopard. Can/should the decision of which flags to pass be made at runtime instead? This is only one of the many different places you'll have to add more logic and runtime checks to WebKit if you want to build a single binary that works well on Tiger, Leopard, and Snow Leopard. Doing that project will be quite challenging! Adding runtime checks would be OK, but the main version of WebKit, built for Mac OS X, should not have such runtime checks. So you'll have to figure out an appropriate way to do the #if so that we don't add unnecessary runtime overhead to the standard Mac OS X WebKit. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Accessibility: Status of MSAA implementation?
Hello all: I noticed some missing functionality in WebKit's implementation of Microsoft Active Accessibility. In particular, the accSelect method ofthe IAccessible interface is not implemented; I've opened a bug on this in Bugzilla. So I'm offering to do some work in this area, but I don't want to duplicate effort. So is anyone else currently working on the MSAA implementation? Thanks. -- Matt Campbell Lead Programmer Serotek Corporation www.serotek.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-dev Digest, Vol 52, Issue 13
Don't know how come she came to my kitchen ..its ground floor and window remains open... It was too young to move around also.. Fed it milk with hand..slowly she got used to us... You take care no problem. :) learning the old ones tend to forget :). Good night ..sweet dreams... Love Prema - Original Message - From: webkit-dev-requ...@lists.webkit.org Sent: 10 September 2009 19:30 To: webkit-dev@lists.webkit.org Subject: webkit-dev Digest, Vol 52, Issue 13 Send webkit-dev mailing list submissions to webkit-dev@lists.webkit.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev or, via email, send a message with subject or body 'help' to webkit-dev-requ...@lists.webkit.org You can reach the person managing the list at webkit-dev-ow...@lists.webkit.org When replying, please edit your Subject line so it is more specific than Re: Contents of webkit-dev digest... Today's Topics: 1. Re: mfenced - more MathML questions (Alex Milowski) 2. Re: Runtime setting for incomplete features (Adam Barth) 3. Re: mfenced - more MathML questions (David Hyatt) 4. Re: Fwd: Whitespace changes (Marc-Antoine Ruel) 5. Re: Runtime setting for incomplete features (Darin Fisher) 6. Re: Runtime setting for incomplete features (Eric Seidel) 7. Re: mfenced - more MathML questions (Alex Milowski) 8. Re: Stretchy Characters (Alex Milowski) 9. Re: mfenced - more MathML questions (David Hyatt) 10. Re: mfenced - more MathML questions (David Hyatt) 11. Re: mfenced - more MathML questions (Alex Milowski) 12. Back/forward cache for pages with unload handlers (Brady Eidson) 13. Re: Back/forward cache for pages with unload handlers (Maciej Stachowiak) 14. Re: Back/forward cache for pages with unload handlers (Brady Eidson) 15. Re: Back/forward cache for pages with unload handlers (Maciej Stachowiak) 16. Re: Back/forward cache for pages with unload handlers (Brady Eidson) -- Message: 1 Date: Wed, 9 Sep 2009 08:16:00 -0700 From: Alex Milowski a...@milowski.org To: webkit-dev Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] mfenced - more MathML questions Message-ID: 28d56ece0909090816w7423002avbe47852a38f8f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 8, 2009 at 4:30 PM, Alex Milowskia...@milowski. [The entire original message is not included] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
I also have a patch (https://bugs.webkit.org/show_bug.cgi?id=28930) that's awaiting a resolution of this for desktop notifications. Does anyone object to putting experimental in the name of the setting as a good solution? -John On Wed, Sep 9, 2009 at 9:50 AM, Eric Seidel e...@webkit.org wrote: experimental would be one option. We used to have build-webkit --svg-experimental iirc. -eric On Wed, Sep 9, 2009 at 9:47 AM, Darin Fisher da...@chromium.org wrote: Perhaps... any suggestions?-Darin On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth aba...@webkit.org wrote: Maybe it's worth distinguishing these settings with some sort of naming convention so that embedders know they'll be removed at some point? Adam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisherda...@chromium.org wrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -Darin ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Passing data structures through postMessage()
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
Regards,
--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
The other approach we discussed was leaving the postMessage() APIs in
WebCore as they are (taking a DOMString parameter) and doing the
serialization/de-serialization in the JS bindings instead.
My one concern about building the serialization into the WebCore postMessage
impls is I didn't quite understand how that would map to ObjC (although for
ObjC we could just continue exposing only postMessage(DOMString) and have
the ObjC bindings wrap the string in an attributeIterator).
My main concern with any approach is that we find a way to share
serialization code between V8 and JSC.
-atw
On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell campb...@flock.com wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
Regards,
--Chris
___
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] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell campb...@flock.com wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
Regards,
--Chris
It should not be necessary to serialize to a string just to pass the
structured clones across thread boundaries. This would be an especially bad
idea for things like CanvasPixelArray. I am also not sure I understand the
name AttributeIterator.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 3:55 PM, Drew Wilson atwil...@google.com wrote: The other approach we discussed was leaving the postMessage() APIs in WebCore as they are (taking a DOMString parameter) and doing the serialization/de-serialization in the JS bindings instead. My one concern about building the serialization into the WebCore postMessage impls is I didn't quite understand how that would map to ObjC (although for ObjC we could just continue exposing only postMessage(DOMString) and have the ObjC bindings wrap the string in an attributeIterator). For the time being, ObjC can be ignored as basic concepts like RegExp are not defined in that context. ObjC can continue living with the old style postMessage and be happy doing so :). -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt oli...@apple.com wrote: This is incorrect, from the bindings point of view the type here should be any, which in the JS bindings means ScriptValue. The actual serialisation is by definition bindings dependent, be that JSC or ObjC. Certainly, from a WebIDL standpoint this is correct. I'm not certain that our current code generator will accept this (the JS bindings are quite flexible especially if we are talking about custom attributes, but my experience with the ObjC generated bindings are that you need to specify concrete classes in the .idl files or else you end up with type errors at compile time - this could obviously be changed). --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
Re: [webkit-dev] Passing data structures through postMessage()
No, it is more restrictive now than it was 6 months ago -- I was attempting to implement this back then and the ambiguity in handling the more excitingly complex objects (now simply return null) made it substantially more complex, that is the only reason the implementation is not currently matching the object clone semantic. JSON was never sufficient for the purpose of postMessage, and is also relatively trivially breakable. --Oliver On Sep 10, 2009, at 5:29 PM, Drew Wilson wrote: Good point - re-reviewing the Structured Clone spec, I see all kinds of crazy stuff is cloneable now, so string/JSON may not be a particularly good basis. It seems that we'll need to support File access from Workers, since you can clone/send those objects over from page context. I had expected that having a common serialization format would be useful, but I agree - it probably is better to just send opaque objects around, which might enable WebKit to send actual cloned object instances without requiring any serialization, while chromium can do the serialization itself when sending the data cross-process. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
I'm not sure that it is actually more restrictive now than it was 6 months ago. I assume you're looking at this: http://www.w3.org/TR/2009/WD-html5-20090212/infrastructure.html#safe-passing-of-structured-data where it seems to say that all host objects (DOM objects, etc) are cloned as null. Sounds like you looked into it in much more detail than I did, so undoubtedly there are ambiguities that aren't obvious at first glance. Anyhow, from April up until two weeks ago, ImageData was the only serialized host object: http://www.w3.org/TR/2009/WD-html5-20090423/infrastructure.html#safe-passing-of-structured-data ...so I'm not totally crazy :) It's a moot point now - while I could (and did :) imagine a reasonably compact one-off serialization for something like ImageData, the addition of the File types on 8/25 (and who knows what else in the future) makes it clear that serialization is not the way to go. -atw On Thu, Sep 10, 2009 at 5:38 PM, Oliver Hunt oli...@apple.com wrote: No, it is more restrictive now than it was 6 months ago -- I was attempting to implement this back then and the ambiguity in handling the more excitingly complex objects (now simply return null) made it substantially more complex, that is the only reason the implementation is not currently matching the object clone semantic. JSON was never sufficient for the purpose of postMessage, and is also relatively trivially breakable. --Oliver On Sep 10, 2009, at 5:29 PM, Drew Wilson wrote: Good point - re-reviewing the Structured Clone spec, I see all kinds of crazy stuff is cloneable now, so string/JSON may not be a particularly good basis. It seems that we'll need to support File access from Workers, since you can clone/send those objects over from page context. I had expected that having a common serialization format would be useful, but I agree - it probably is better to just send opaque objects around, which might enable WebKit to send actual cloned object instances without requiring any serialization, while chromium can do the serialization itself when sending the data cross-process. -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
Given shared workers (and indeed Chromium's out-of-process dedicated
workers), it seems like we also have cross process boundaries to consider.
-Darin
On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 3:12 PM, Chris Campbell wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
Some thoughts off the cuff:
I think it would be better to write custom code for doing the cloning for
each JS engine. For one thing, turning everything into a string is not
necessarily the most efficient way to do things. It might be possible to
clone the object graph more directly in a threadsafe way. Also, things like
File and ImageData fundamentally can't be turned into a string (well
ImageData can)
Second, to be really agnostic about it, postMessage should take a generic
Message object that has some methods that can be used to do the cross-thread
clone without building in the assumption that it serializes to a string in
the middle.
Third, using a stateful iterator for this instead of an interface
representing a value is not a great design. Iterators are not good when what
you are traversing is in general a graph.
Fourth, this doesn't give a way to detect if an object graph is not in fact
legal to clone.
It's kind of a shame that we have the baggage of multiple JavaScript
engines to contend with. Trying to do things in a generic way will make this
task needlessly more difficult.
You may also want to get input on this from Oliver Hunt, who wrote the JSC
JSON parse/stringify code; from past discussions I know has opinions on how
cross-thread cloning should work.
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
In general I'm not sure this approach is workable. At the very least File,
FileData, FileList and ImageData need to be passed as something other than
strings. And I think the value of making the object graph traversal code
generic while everything else is JS-engine-specific is pretty low. In
addition, I do not think the proposed interface is adequate to implement the
cloning algorithm.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
