[webkit-dev] Is there a way to call JavaScript easily

[douchuan]

I'm doing a research that extends Java to a dynamic language using
JavaScript.
I have readed some docs about SpiderMonkey, Rhino, JavaScriptCore, but
lots of information just
about how to call Java from JS easily, but there isn't any information
how to
call JS from Java. Is there possibility about my study?

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

Re: [webkit-dev] willCacheResponse

[Brady Eidson]

willCacheResponse was lumped in with dumpResourceLoadCallbacks()  
solely for convenience based on the situation at the time.


As you point out, it is only interesting for embedders of mainline  
WebKit on Mac.


My two proposals are to either split off a new dumpWillCacheResponse()  
callback or change dumpResourceLoadCallbacks() to take a second  
argument that is false by default.


I slightly prefer the latter.

I've filed https://bugs.webkit.org/show_bug.cgi?id=28010 to track this.

~Brady

On Aug 4, 2009, at 5:35 PM, Darin Fisher wrote:

There is a Mac-only willCacheResponse notification that gets  
recorded by several of the layout tests when  
layoutTestController.dumpResourceLoadCallbacks(true) is called.   
However, this notification which originates at the ResourceHandle  
level is currently #if PLATFORM(MAC).  I noticed that the tests  
which depend on this notification are currently skipped on platform/ 
win.  For Chromium, we have simply rebaselined with the  
willCacheResponse events excluded.  Having a separate baseline is  
unfortunate and not running the tests on platform/win seems even  
worse.


I wonder if it wouldn't be better to exclude willCacheResponse by  
default, and then only enable it selectively for tests that are  
about testing it.  That way, we can un-skip the other tests that  
only fail on non-Mac as a side-effect of this notification not being  
supported.  We could also try to support willCacheResponse on all  
platforms, but that seems like a lot of work for little gain.   
Afterall, it is a notification that WebKit doesn't itself care  
about.  It is just something provided to the embedder of the WebKit  
Framework on Mac.


I didn't see any bugs on file about this issue.

-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] willCacheResponse

[Darin Fisher]

There is a Mac-only willCacheResponse notification that gets recorded by
several of the layout tests when
layoutTestController.dumpResourceLoadCallbacks(true) is called.  However,
this notification which originates at the ResourceHandle level is currently
#if PLATFORM(MAC).  I noticed that the tests which depend on this
notification are currently skipped on platform/win.  For Chromium, we have
simply rebaselined with the willCacheResponse events excluded.  Having a
separate baseline is unfortunate and not running the tests on platform/win
seems even worse.
I wonder if it wouldn't be better to exclude willCacheResponse by default,
and then only enable it selectively for tests that are about testing it.
 That way, we can un-skip the other tests that only fail on non-Mac as a
side-effect of this notification not being supported.  We could also try to
support willCacheResponse on all platforms, but that seems like a lot of
work for little gain.  Afterall, it is a notification that WebKit doesn't
itself care about.  It is just something provided to the embedder of the
WebKit Framework on Mac.

I didn't see any bugs on file about this issue.

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

Re: [webkit-dev] scroll areas of 's

[Darin Adler]

On Aug 4, 2009, at 2:57 PM, Chris Fleizach wrote:

How do the scroll areas that encompass text areas fit into the  
render tree?


I need to turn that scroll area into an accessible object, but when  
I look at the render tree i don't see anything that would indicate  
there is a renderer associated with the scroll area.


The class that handles this is RenderTextControlMultiLine, which is  
derived from RenderTextControl, then from RenderBlock. Like any other  
block, if the CSS overflow is set appropriately there can be scroll  
bars. You should see a RenderTextControlMultiLine in the render tree,  
with functions like scrollsOverflowX() and scrollsOverflowY()  
indicating the presence of scroll bars.


-- Darin

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

[webkit-dev] scroll areas of 's

[Chris Fleizach]

How do the scroll areas that encompass text areas fit into the render  
tree?


I need to turn that scroll area into an accessible object, but when I  
look at the render tree i don't see anything that would indicate there  
is a renderer associated with the scroll area.


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

[webkit-dev] Care and feeding of the commit-queue flag

[Adam Barth]

If you're not interested in automating patch landings, you can ignore
this message.

As of this weekend, we have an experimental commit queue working.  The
queue still requires a bunch of manual attention from me, but I'm
hoping to gradually reduce that over time without changing the
interface.  Here's how to use the queue:

* If you're a committer, you can approve a reviewed patch for the
commit queue by setting the commit-queue+ flag on the patch.  The next
time the commit queue scans Bugzilla, it will pick up the patch, build
it, test it, and land it.

The primary use case is if you just reviewed a patch by a
non-committer, you can set the commit-queue+ flag at the same time as
the r+ flag and the commit queue will take care of committing the
patch for you.

WARNING: Approving a patch for the commit queue (i.e., setting the
commit-queue+ flag) is the moral equivalent of committing the patch.
You should only set this flag if you would otherwise commit the patch.
 The commit queue does some sanity checks (like making sure the patch
has an r+ from a reviewer), but you should exercise your good
judgement.

Frequently Asked Questions:

Q) This commit queue thing is dumb.  Can I opt out?
A) Sure!  Just ignore the commit-queue flag and use whatever workflow you like.

Q) How does the commit queue know I'm a committer?
A) It looks at 
.
 We're missing a bunch of committers.  If you'd like to be listed,
send me a patch.  :)

Q) How often does the commit queue scan Bugzilla for approved patches?
A) When I'm running the queue, it scans every 10 minutes.  I'm
probably more likely to run the queue at night for a while to avoid
disrupting the tree.

Q) Can I see my patch make progress through the commit queue?
A) Not yet.  I need to figure out how to give feedback.  Currently it
spews a bunch of text to a terminal on my machine, but no one else can
see that.

Q) Help! The commit queue destroyed the tree!
A) Please look for me on IRC and we'll figure out what went wrong.

Q) This commit queue thing is great!  Can I run the commit queue on my machine?
A) Almost all the code is checked into SVN.  The only missing piece is
the master process that controls the queue.  If you're really
interested, I can check in this script, but my current plan is to
iterate on it a few times.

Q) What platforms does the commit queue build / test?
A) Currently, it just builds and tests the Mac port on my laptop.  As
try servers come online, we can integrate them into the commit queue
for better pre-commit coverage.

Thanks for your patience while we try out this system.  Hopefully it
will be useful.

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

Re: [webkit-dev] freeing static variables

[Zoltan Herczeg]

Hi Adam,

thank you for your suggestions. I have something similar in my mind.

I have opened a bugzilla entry and submited an early patch draft about my
concept:
https://bugs.webkit.org/show_bug.cgi?id=27980

The patch frees memory objects in a reversed creation order, and seemed
working well with QtLauncher (although only a subset of static variables
are freed right now). Do you know about special cases when this approach
is not enough?

Actually it is hard to find real memory leaks in the output of valgrind
because many of them are related to static variables. I hope this feature
will help to the leak hunters in the future.

Cheers,
Zoltan

> On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
>> Hi,
>>
>> any thoughts on this? I hope my qestion was clear :) I would like to
>> pack
>> the static declarations into wrapper classes, so we can add platform
>> and/or compilation mode (debug/release) dependent functionality to all
>> static variables (i.e: freeing them on exit).
>>
>> Zoltan
>
> I've tried this before and it didn't work out so well.  The order in which
> you
> free them becomes very important and error prone.
>
> And, of course, whatever solution you make has to be optional and easy to
> maintain as the default policy in WebKit is to not care - by design -
> about
> cleaning up after static globals on exit as that is left to the OS.
>
> Another strategy for the embedded case where you want to free everything
> on
> exit is to create a custom memory handler that will do this for you.
>
> Cheers,
> Adam


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