[webkit-dev] click() method for anchor and img elements in WebKit API
Hi According to https://developer.mozilla.org/en/DOM/element.click Gecko does not support click() method on some elements (like anchor or img). Does WebKit support click() method on anchor and img elements? If not are there any plans to support it and is it possible to implement this functionality atop of current API? I'm using Qt port of WebKit and it would be enough for me if this port would have such a function in its API. -- Piotr Dobrogost *** curlpp.org - c++ wrapper for libcurl *** ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SLL_Pop list is not checked for NULL
In JavaScriptCore/wtf/FastMalloc.cpp:696
The list should be checked for NULL. Eg.
static inline void *SLL_Pop(void **list) {
if (!list || !(*list))
return NULL;
void *result = *list;
*list = SLL_Next(*list);
return result;
}
Greets,
Luka
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a commit-queue
Adam Barth wrote: On Sat, Aug 1, 2009 at 1:13 PM, David Kilzerddkil...@webkit.org wrote: Either we should change the review process to only set the review+ flag if the patch is ready to go with zero modifications, or we should use the commit+ flag to signify that. I could go either way on this. I don't like the idea of setting review- flags for trivial fixes that could be landed with minor modifications. On the other hand, being able to commit patches directly from bugs.webkit.org with bugzilla-tool is really handy. The other factor is that some committers might not want the commit-queue script to land their changes. In those cases, their patches would get an r+ but never get a commit+. (Personally, I don't mind if other people want to land may changes, but I can see how it might disrupt other's workflow.) Based on this, I suggest calling the flag auto-commit, to make it clear that you don't need to set it if you want to commit by hand. Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reporting exceptions from worker context to users
Drew Wilson wrote: OK, I really wanted to gloss over this, but now Jeremy's going to make me elaborate :) There are a few things I think we will eventually need to support worker development: 1) Some way to print out the values of things in a worker's global scope. 2) Similar debugging support for workers that we have for page script (breakpoints, etc). 3) When the user is selecting a worker for #1/#2, it might be useful to indicate what the parent(s) of the worker are to help developers select the right worker (in case there are nested workers). Or maybe it's not very useful - perhaps just having the URL of the worker base script is sufficient. We don't know yet. What immediately comes to mind here is the Eclipse Java debugger. Single window that shows a list of connected VMs. Each VM contains a list of threads. In the Web Browser World, thread might correspond to worker, and perhaps would be a tree of workers instead of list of threads, to indicate nesting. The current story with Web Inspector is that a Web Inspector is associated with a window object. So the concept of supporting muliple windows like Eclipse supports multiple processes wouldn't make sense. Doesn't rule out supporting it in the future though - a single Web Inspector window instead of multiple. And someone might want to make a stand-alone JS debugger with the inspector code, that could somehow connect to multiple running JS engines simultaneously. Then the rest of the Web Inspector story, as far as the Scripts panel, works the same. Instead of just selecting a frame to operate on, you will also have a worker (or the main thread) to select on. Selecting a new worker changes. Presumably we'd change the Call Stack section, or add a new section above Call Stack called Worker (not a great name, but you know what I mean). I suppose we should open an enhancement bug ... -- 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] Towards a commit-queue
On Aug 1, 2009, at 8:41 PM, Adam Barth wrote: On Sat, Aug 1, 2009 at 1:13 PM, David Kilzerddkil...@webkit.org wrote: Either we should change the review process to only set the review+ flag if the patch is ready to go with zero modifications, or we should use the commit+ flag to signify that. I could go either way on this. I don't like the idea of setting review- flags for trivial fixes that could be landed with minor modifications. On the other hand, being able to commit patches directly from bugs.webkit.org with bugzilla-tool is really handy. The other factor is that some committers might not want the commit-queue script to land their changes. In those cases, their patches would get an r+ but never get a commit+. (Personally, I don't mind if other people want to land may changes, but I can see how it might disrupt other's workflow. I think the flag state should be commit? for requesting a commit, and commit+ for a committed patch, to match how we use the review flag. That way, either the patch submitter or anyone else who notices the patch needs committing and wasn't submitted by a committer can flag it, and the state when the patch is landed can be clear. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SLL_Pop list is not checked for NULL
On Aug 3, 2009, at 5:00 AM, Luka Napotnik wrote: In JavaScriptCore/wtf/FastMalloc.cpp:696 The list should be checked for NULL. No, that’s incorrect. The code is fine as it is. There’s only one caller and that caller guarantees that neither list nor *list is 0. Is there some reason you think this change is necessary? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SLL_Pop list is not checked for NULL
Dne 03.08.2009 (pon) ob 09:51 -0700 je Darin Adler zapisal(a): On Aug 3, 2009, at 5:00 AM, Luka Napotnik wrote: In JavaScriptCore/wtf/FastMalloc.cpp:696 The list should be checked for NULL. No, that’s incorrect. The code is fine as it is. There’s only one caller and that caller guarantees that neither list nor *list is 0. Is there some reason you think this change is necessary? Oh didn't trace SLL_Pop() back to Pop() to see the ASSERT(). I was just walking the source and noticed. -- Darin Greets, Luka ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] initializing protected variable in a subclass
I have added
protected:
AccessibilityRole m_role;
to AccessibilityObject.h
I want to initialize that variable in subclasses of
AccessibilityObject, like so
AccessibilityImageMapLink::AccessibilityImageMapLink()
: m_role(WebCoreLinkRole)
but the compiler says
/Volumes/data/WebKit/WebCore/accessibility/
AccessibilityImageMapLink.cpp:48: error: class
‘WebCore::AccessibilityImageMapLink’ does not have any field named
‘m_role’
even though this works fine
AccessibilityImageMapLink::AccessibilityImageMapLink()
{
m_role = WebCoreLinkRole;
}
any tips?
thanx___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] initializing protected variable in a subclass
Make your base class constructor take the role as an argument. Then
the subclasses can just pass in the value they want to use to
initialize it
e.g.,
AccessibilityObject(AccessibilityRole role)
: m_role(role)
{
}
and then in the subclass
AccessibilityImageMapLink()
: AccessibilityObject(WebCoreLinkRole)
{
}
Another option is to just forego the member variable storage and make
a virtual function that returns the role. That only works if the role
can be determined from the subclasses though.
virtual AccessibilityRole role() const { return WebCoreLinkRole; }
Hope this helps,
dave
(hy...@apple.com)
On Aug 3, 2009, at 5:51 PM, Chris Fleizach wrote:
I have added
protected:
AccessibilityRole m_role;
to AccessibilityObject.h
I want to initialize that variable in subclasses of
AccessibilityObject, like so
AccessibilityImageMapLink::AccessibilityImageMapLink()
: m_role(WebCoreLinkRole)
but the compiler says
/Volumes/data/WebKit/WebCore/accessibility/
AccessibilityImageMapLink.cpp:48: error: class
‘WebCore::AccessibilityImageMapLink’ does not have any field named
‘m_role’
even though this works fine
AccessibilityImageMapLink::AccessibilityImageMapLink()
{
m_role = WebCoreLinkRole;
}
any tips?
thanx
___
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] Towards a commit-queue
OK, per the discussion, I will add a commit-queue=? flag for Adam's testing. If we like it, we can keep it. If not, we can kill it. -eric On Mon, Aug 3, 2009 at 9:43 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 1, 2009, at 8:41 PM, Adam Barth wrote: On Sat, Aug 1, 2009 at 1:13 PM, David Kilzerddkil...@webkit.org wrote: Either we should change the review process to only set the review+ flag if the patch is ready to go with zero modifications, or we should use the commit+ flag to signify that. I could go either way on this. I don't like the idea of setting review- flags for trivial fixes that could be landed with minor modifications. On the other hand, being able to commit patches directly from bugs.webkit.org with bugzilla-tool is really handy. The other factor is that some committers might not want the commit-queue script to land their changes. In those cases, their patches would get an r+ but never get a commit+. (Personally, I don't mind if other people want to land may changes, but I can see how it might disrupt other's workflow. I think the flag state should be commit? for requesting a commit, and commit+ for a committed patch, to match how we use the review flag. That way, either the patch submitter or anyone else who notices the patch needs committing and wasn't submitted by a committer can flag it, and the state when the patch is landed can be clear. 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
