Re: [webkit-dev] Creating custom DOM events
On 08.04.2009, at 3:10, Ross Lillie wrote:
element onMyCustomEvent=function() {}
The public interfaces in WebKit don't appear to provide the
functionality I
need. The private interfaces in WebCore appear that they might. Am
I on
the right track?
WebCore internal methods are subject to frequent changes, so calling
them directly is not recommended.
You can avoid the need to do add the custom attribute by not using it,
and registering the event handler via element.addEventListener() in
your JavaScript code.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fw: not enough space error???
I just checked out r42317 and the problem persists. Can you give me info on the error report or patch number? Thanks, Frank From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ben Murdoch Sent: 2. april 2009 20:20 To: Sverrir Á. Berg Cc: Aman; webkit-dev Subject: Re: [webkit-dev] Fw: not enough space error??? Hi guys, FYI, I sent a patch and this is fixed in r42175 for 32-bit setups. Thanks, Ben 2009/4/1 Sverrir Á. Berg sver...@chromium.orgmailto:sver...@chromium.org I've had this problem and I've heard of others. My solution was switching to a Mac for development. Number of people have no problems building with that setup but I think the mainstream setup for Windows is moving towards 64-bit Vista with lots of memory (but still building 32-bit)... Sverrir 2009/4/1 Ben Murdoch bmurd...@gmail.commailto:bmurd...@gmail.com Hi, I'm running into the same problem, C1083 (not enough space) trying to link WebCore.lib on Windows XP SP3 in Cygwin (working with r42007). I've tried setting the /3GB boot option, but that doesn't seem to help. Were you able to solve this problem Aman? Has anyone else run into it and found a solution? Debug builds work fine for me. Thanks, Ben 2008/12/13 Justin Haygood jhayg...@reaktix.commailto:jhayg...@reaktix.com No, but all the source code and object files used to create it are. - Original Message - From: Amanmailto:zhaiqi...@gmail.com To: webkit-devmailto:webkit-dev@lists.webkit.org Sent: Saturday, December 13, 2008 2:08 AM Subject: [webkit-dev] Fw: not enough space error??? Hi, The release version of the WebCore.lib is about 1.2G, not really??? anybody knows that?? Aman From: Amanmailto:zhaiqi...@gmail.com Sent: Saturday, December 13, 2008 1:59 PM To: aro...@apple.commailto:aro...@apple.com Cc: webkit-devmailto:webkit-dev@lists.webkit.org Subject: not enough space error??? Hi, Adam and everybody: I received this error the message while building WebCore(release) as someone else before: Linking... fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\Administrator\webkit\WebKitBuild\lib\WebCore.lib': Not enough space and i saw your post message about this error , but i think it is not like https://bugs.webkit.org/show_bug.cgi?id=19743.(i am using the newest version) Aman ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Ben Murdoch http://www.omgwtf.me.uk b...@omgwtf.me.ukmailto:b...@omgwtf.me.uk | bmurd...@gmail.commailto:bmurd...@gmail.com ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] nodeAtPoint is very confusing
Dave, Simon, and other rendering gurus: bool RenderObject::nodeAtPoint(const HitTestRequest, HitTestResult result, int _x, int _y, int tx, int ty, HitTestAction hitTestAction) _x, _y, tx, ty are very confusing. As far as I can tell, _x, _y are relative to the root layer (which can change during hit-testing!) and tx, ty are more of the HTML offset to your parent optimization which painting uses. Can you explain what the best way to convert from _x, _y to local coordinates? And what I should rename _x, _y, and tx, ty to in a forthcoming make hit testing readable to normal humans cleanup patch? Thanks again. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] FW: Creating custom DOM events
Thanks for the reply.
To clarify, it¹s the external process generating an event representing the
process¹ completion status that I want to dispatch into a DOM target. I
understand that I can simply add and event listener to a DOM element,
however if I want my custom event handler to be an attribute of a DOM
element, then I¹m assuming that I need to a) create a custom DOM attribute
that b) implements the EventTarget interface. My external code then
dispatches it¹s custom event to my custom attribute/eventTarget. This would
then allow my HTML markup to be of the form:
div onMyExternalProcessComplete=function()
I¹m not saying that this is necessarily the best way to accomplish this, but
am just trying to understand how everything is connected within the webkit
framework. However, if my understanding is correct, then what is the best
way to add a custom attribute/eventTarget into the DOM?
thanks again for the insights,
Ross
On 4/8/09 4:10 AM, ZHOU Xiao-bo zhxb.u...@gmail.com wrote:
external code to be able to dispatch custom events
you mean that your c++ code can be triggered by a custom event or your code
can
generate a custom envent?
if former, I think you should implement your own onxxx attribute, and add some
eventlisteners;
if latter, maybe you can add your own eventlistener to some node and create an
event and call
handlelocalevent
2009/4/8 Ross Lillie ross.lil...@motorola.com
I have external C++ code that I'm exposing to the JavaScript runtime. I'd
also like my external code to be able to dispatch custom events via the DOM
event mechanism. For example
element onMyCustomEvent=function() {}
Now, if I'm beginning to understand Webkit (which is doubtful) it seems that
I need to somehow create a new attribute node that's wired to my external
code and serves as the EventTarget for event dispatches. I.e. somewhat
similar to how this is described for Mozilla/Gecko
The public interfaces in WebKit don't appear to provide the functionality I
need. The private interfaces in WebCore appear that they might. Am I on
the right track?
If so, how are new elements added to the DOM? Is this the function of the
NamedNodeMap, or am I completely lost in my understanding? Also, I'm
assuming any custom event must also be registered somewhere.
Thanks in advance for any insight or pointers to more information.
Ross
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- End of Forwarded Message
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] nodeAtPoint is very confusing
On Apr 8, 2009, at 7:06 AM, Eric Seidel wrote: Dave, Simon, and other rendering gurus: bool RenderObject::nodeAtPoint(const HitTestRequest, HitTestResult result, int _x, int _y, int tx, int ty, HitTestAction hitTestAction) _x, _y, tx, ty are very confusing. As far as I can tell, _x, _y are relative to the root layer (which can change during hit-testing!) and tx, ty are more of the HTML offset to your parent optimization which painting uses. Can you explain what the best way to convert from _x, _y to local coordinates? And what I should rename _x, _y, and tx, ty to in a forthcoming make hit testing readable to normal humans cleanup patch? As I understand it, _x and _y are relative to tx, ty, which in turn is relative to the rootLayer. In general tx and ty, as passed to painting and hit testing functions, are the offsets that put you in the coordinate space of the parent renderer, relative to the current rootLayer being used for painting or hit testing (which, as you note, gets reset for transforms, and I think should also get reset for HTML/SVG boundaries). So to get local x and y for hit testing, you'll see code like: tx += x(); ty += y() ... updateHitTestResult(_x - tx, _y - ty) It is all rather confusing, but much of the complexity comes from having to deal with inlines. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Allowing webkit clients to extend XHR security policy
Hello all, I'm working on adding extensions (aka Add-Ons) to Chromium. One thing we want to enable these extensions to do is to make limited cross-origin XMLHttpRequests. Rafael Weinstein, who is working with me, consulted with Adam Barth and submitted a patch based on his ideas https://bugs.webkit.org/show_bug.cgi?id=24853 for this a few weeks back. It has met with resistance though, and we're not really sure where to go next. So I wanted to back up, explain what we're trying to do at a high level and get suggestions for the best way to implement this. The Goal: We want extension developers to be able to access multiple origins, but for them to have to declare those origins ahead of time. The origins would be declared using a pattern syntax, something like 'http://*.google.com'. Having to declare the origins ahead of time reduces the damage a compromised extension can do because it can only be used to access a subset of origins. Most use cases we envision really only need to access a few origins, so this would be a big win for us. This also seems like this is something that could be generally useful for other webkit clients. I can imagine browsers wanting to offer increased privilege modes to web apps, and then wanting to do similar restrictions on access to cross-origin XHR. Ideas: 1) A static call out of WebKit to a client from SecurityOrigin. This is the current patch. A few problems people have brought up with it: * Some people don't like the idea that the callback gets invoked on multiple threads. * some people think it's ugly to have SecurityOrigin making calls out to static methods and think it should have a normal instance client. 2) Non-static SecurityOriginClient. I suggested this in the last comment on the bug. The creator of a SecurityOrigin would have the option to set a client which it could retrieve from FrameLoaderClient (or some other client?). This doesn't solve the problem of getting callbacks on multiple threads, but we could skip implementing it for workers and when the refactor to move origin checking for workers to the UI thread happens, it will automatically start working. 3) Something more specific to XMLHttpRequest. Since we're really only interested in modifying the behavior of XMLHttpRequest, it might be nicer to do something more targetted than SecurityOrigin. I was hoping that I could add a method to FrameLoaderClient and call it from XHR, but I don't see a nice way to get to FrameLoaderClient from XHR. 4) Refactor all access checking (current same-origin checks, local scheme stuff, preflight stuff for AC) into DocumentThreadableLoader. Then add a new callback for what we want on FrameLoaderClient. One meta-question I have about this approach is whether it's really the right thing to do XHR-specific access checks in DocumentThreadableLoader and friends. In general, I'd rather not embark on a big refactor to get this done, but I'm still open to it if that's the only option. That's about all the ideas I've come up with. Are any of them appealing? Is there some other approach that would be better? I think we can also do this outside of WebCore with some hacking, but I'd rather avoid that and contribute some useful code to WebKit at the same time if possible. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] nodeAtPoint is very confusing
Yeah this was on my list of things to do, but I stopped my big render tree refactoring for the sake of stability. I think we should hold off on more big changes to render tree methods for now. dave On Apr 8, 2009, at 5:50 PM, Maciej Stachowiak wrote: On Apr 8, 2009, at 9:23 AM, Simon Fraser wrote: On Apr 8, 2009, at 7:06 AM, Eric Seidel wrote: Dave, Simon, and other rendering gurus: bool RenderObject::nodeAtPoint(const HitTestRequest, HitTestResult result, int _x, int _y, int tx, int ty, HitTestAction hitTestAction) _x, _y, tx, ty are very confusing. As far as I can tell, _x, _y are relative to the root layer (which can change during hit-testing!) and tx, ty are more of the HTML offset to your parent optimization which painting uses. Can you explain what the best way to convert from _x, _y to local coordinates? And what I should rename _x, _y, and tx, ty to in a forthcoming make hit testing readable to normal humans cleanup patch? As I understand it, _x and _y are relative to tx, ty, which in turn is relative to the rootLayer. In general tx and ty, as passed to painting and hit testing functions, are the offsets that put you in the coordinate space of the parent renderer, relative to the current rootLayer being used for painting or hit testing (which, as you note, gets reset for transforms, and I think should also get reset for HTML/SVG boundaries). So to get local x and y for hit testing, you'll see code like: tx += x(); ty += y() ... updateHitTestResult(_x - tx, _y - ty) It is all rather confusing, but much of the complexity comes from having to deal with inlines. Maybe one thing that would help would be combining (tx, ty) into an IntPoint and (_x, _y) into an IntSize (since it as an offset from the point established by tx, ty). Or vice versa. Regards, Maciej ___ 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] about WTF::HashMap::iterator
hi all:
WTF::Hashmap::iterator uses WTF::HashTable::iterator as its m_impl.
When you call 'remove( oldIter )', the current 'iter' may be changed. And
it's not about memory reallocation or element shift, but it's because the
member variable 'm_table' in WTF::HashTable::iterator may become NULL
if there is only one entry in the HashMap before you call remove( olditer ).
So, how can I delete an element of a HashMap when I traversing the
container? e.x.
while( iter ) {
oldIt = iter;
++iter;
remove( oldIT ); // not always safe
}
thx
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
