[webkit-dev] [QtWebKit] exposing JScript Objects to Clients

2009-09-29 Thread Robert Hogan
Hi there,

At the moment WebKit does not deliberately expose any of the properties of 
Javascript objects to clients. Those it does expose seem to be as much by 
luck as anything else. One example is navigator.useragent, which in Qt's 
case ultimately returns whatever the client has set in userAgentForUrl().

The more common case is illustrated by the other properties of the 
navigator object. Here is the return value for navigator.appname as defined 
in NavigatorBase.cpp:

String NavigatorBase::appName() const
{
return Netscape;
}

I would like to make it possible for the client to control the values 
returned by JS objects - this is so that my project (http://torora.net) can 
ensure that the anonymity set of torora's users is properly preserved. For 
example, Torora would always ensure that the value returned for 
navigator.platform would be 'WinXP' (regardless of the user's actual OS). 
This would protect the user from a website collating information on a user 
and possibly uniquely identifying them.[1]

The only way I can think of providing this API is as follows (taking the 
navigator object as an example):

1. Copy WebCore/page/Navigator.cpp to WebCore/page/qt/NavigatorQt.cpp and 
exclude Navigator.cpp from the Qt build.

2. In NavigatorQt.cpp implement the return values by calling virtual 
functions in QWebPage. Following the example of userAgentForUrl() this 
would take the form of:

String NavigatorBase::appName() const
{
 String appName =  m_frame-loader()-appName();
 if (appName.isEmpty())
return NavigatorBase::appName();
 return appName;
}

which calls:

String FrameLoaderClientQt::appName()
{
if (m_webFrame) {
return m_webFrame-page()-appName();
}
return String();
}

where page()-AppName() is a virtual function in QWebPage that returns an 
empty string if it is not reimplemented by the client.

3. NavigatorQt.cpp would have to do this for all elements of the navigator 
object that it wanted to offer for client control.

The same approach would have to be used for the date, screen and window 
objects, though in the case of Torora there are other ways of ensuring 
those values do not give away anything so my only actual requirement at the 
moment is to control the navigator object,

I see a couple of disadvantages to this approach:

1. Likely performance hit.
2. Customized implementations of functions in the qt/ folder of the 
WebCore/page directory are for functions not implemented at all in the base 
code, rather than for replacing the ones that are.
3. It's a very cumbersome way of doing things.

A proper hooking mechanism (where clients could control all javascript 
objects) for javascript would seem to require a major overhaul to 
webcore/javascriptcore, and I have no idea how it would work or even if it 
would be possible. 

So my questions are:

 - Is the above approach acceptable for QtWebKit?
 - Is there any effort already underway for a hooking mechanism for jscore?
 - Is there an alternative approach anyone can think of?

[1] Torora already does this by providing a patch to webkit when building 
from source. The patch crudely overrides existing values with a 'safe' set 
of hardcoded values.

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


Re: [webkit-dev] Custom HTML Tags

2009-09-29 Thread Eric Seidel
Sounds like you want XBL. :)

On Mon, Sep 28, 2009 at 8:27 PM, Chris Frost chrisfros...@gmail.com wrote:

 Hello All,

 I am thinking about creating some custom HTML tags to abstract the process
 of creating graphical widgets such as clock and calendar. To make it work, I
 would imagine I need some interpreter to transform the custom tags to
 HTML/CSS/JS before rendering the page. I heard a lot of great things about
 Webkit, but I am quite new to its codebase. I am wondering if Webkit is the
 right technology to solve my problem. Any pointers would be very much
 appreciated.

 Thank you in advance!

 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] [QtWebKit] exposing JScript Objects to Clients

2009-09-29 Thread Oliver Hunt
If your goal is to specify the useragent string that can be done  
entirely in the API layer without modifying WebCore at all (this is  
how Mac browsers built on the system WebKit specify their app name).   
The changes you're requesting should not involve WebCore in any way.


If you're wanting to manipulate the DOM that is purely a matter of  
having a DOM binding for Qt or just getting the js global object and  
using the standard JSC APIs to manipulate it.


--Oliver

On Sep 21, 2009, at 10:58 AM, Robert Hogan wrote:


Hi there,

At the moment WebKit does not deliberately expose any of the  
properties of
Javascript objects to clients. Those it does expose seem to be as  
much by
luck as anything else. One example is navigator.useragent, which in  
Qt's
case ultimately returns whatever the client has set in  
userAgentForUrl().


The more common case is illustrated by the other properties of the
navigator object. Here is the return value for navigator.appname as  
defined

in NavigatorBase.cpp:

String NavigatorBase::appName() const
{
   return Netscape;
}

I would like to make it possible for the client to control the values
returned by JS objects - this is so that my project (http:// 
torora.net) can
ensure that the anonymity set of torora's users is properly  
preserved. For

example, Torora would always ensure that the value returned for
navigator.platform would be 'WinXP' (regardless of the user's actual  
OS).
This would protect the user from a website collating information on  
a user

and possibly uniquely identifying them.[1]

The only way I can think of providing this API is as follows (taking  
the

navigator object as an example):

1. Copy WebCore/page/Navigator.cpp to WebCore/page/qt/ 
NavigatorQt.cpp and

exclude Navigator.cpp from the Qt build.

2. In NavigatorQt.cpp implement the return values by calling virtual
functions in QWebPage. Following the example of userAgentForUrl() this
would take the form of:

String NavigatorBase::appName() const
{
String appName =  m_frame-loader()-appName();
if (appName.isEmpty())
   return NavigatorBase::appName();
return appName;
}

which calls:

String FrameLoaderClientQt::appName()
{
   if (m_webFrame) {
   return m_webFrame-page()-appName();
   }
   return String();
}

where page()-AppName() is a virtual function in QWebPage that  
returns an

empty string if it is not reimplemented by the client.

3. NavigatorQt.cpp would have to do this for all elements of the  
navigator

object that it wanted to offer for client control.

The same approach would have to be used for the date, screen and  
window

objects, though in the case of Torora there are other ways of ensuring
those values do not give away anything so my only actual requirement  
at the

moment is to control the navigator object,

I see a couple of disadvantages to this approach:

1. Likely performance hit.
2. Customized implementations of functions in the qt/ folder of the
WebCore/page directory are for functions not implemented at all in  
the base

code, rather than for replacing the ones that are.
3. It's a very cumbersome way of doing things.

A proper hooking mechanism (where clients could control all javascript
objects) for javascript would seem to require a major overhaul to
webcore/javascriptcore, and I have no idea how it would work or even  
if it

would be possible.

So my questions are:

- Is the above approach acceptable for QtWebKit?
- Is there any effort already underway for a hooking mechanism for  
jscore?

- Is there an alternative approach anyone can think of?

[1] Torora already does this by providing a patch to webkit when  
building
from source. The patch crudely overrides existing values with a  
'safe' set

of hardcoded values.

___
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 script plugin

2009-09-29 Thread 张正和
Hello all
    Now, I have a problem and I don't konw how to solve it, I hope you 
help me, thank you!
    I have written a scripting plugin with NPAPI and this plugin has 
some properties and methods. it has a intValue property and two methods of 
getValue and setValue. Now I don't konw when and where to call the 
functions(NPN_Invoke(), NPN_GetProperty()) in NPAPI , Could you give me a 
example?
thank you!
 
This is my web page for testing object plugin,please see the HTML code:
testObject.htm
html
head
titleplugin example/title
script type=text/javascript
function fun()
{
    elem = document.getElementById(para1);
 alert(elem.intValue);
 var value = 5;
 elem.setValue(value);
 var intValue = elem.getValue();
 alert(intValue); 
}
/script
/head
body
object id=para1 type=clsid:72E6F181-D1B0-4C22-B0D7-4A0740EEAEF5
    param name=bgcolor value=#c6cfd0 /
    param name=jad value=Mp3/TestSound.jad /
    param name=jar value= Mp3/TestSound.jar /
/object
button onclick=fun();Button/button
/body
/html



  ___ 
  好玩贺卡等你发,邮箱贺卡全新上线! 
http://card.mail.cn.yahoo.com/___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Leak reports during shutdown

2009-09-29 Thread Zoltan Herczeg
Hi Kevin,

WebKit approach is NOT to free memory before quit to make the quit process
as fast as possible. The memory manager should free the unfreed objects.
However, this approach makes really hard to find the real leaks (which
are unreferenced objects).

In my experince the unfreed (non-leak) objects come from several sources:
  - JavaScriptCore garbage collector is not called before quit
  - Caches are not cleared before quit
The previous two are performed by QtLauncher in debug mode. See
WebKit/qt/QtLauncher/main.cpp launcherMain()
  - In case of workers, the gc() does not called for each worker threads
when the application quits. The JavaScript threads are simply aborted.
  - Global objects are not freed at all. There was an attempt to free them
(see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not worth
to continue that work, although it helped to find leaks such as this:
https://bugs.webkit.org/show_bug.cgi?id=29295

The remaining unfreed objects are possible leaks. Many of them are
probably port specific (not all port maintainers have resources to keep
leak hunters).

Zoltan

 Hi all,

 For a while, ports like wx and Win/Cairo have been seeing various
 leaks reported on shutdown, but at least on Mac I've been unable to
 see these leaks using memory leak checkers like the one in
 Instruments, so I decided to poke into the code a bit more and try to
 understand what's going on a bit better.

 What I found was that the reported object leaks were pretty much all
 related to objects that JSC has references to. Changing
 ~ScriptController to do a garbageCollectNow() instead of
 garbageCollectSoon(), for example, drastically reduced the number of
 reported leaks, cleaning up all the CachedResource leaks and almost
 all the WebCoreNode leaks. The remaining leaks were almost all
 JSC::Structure objects. I've been digging through the code to try and
 find the place where these JSC objects are finally deleted, but I
 haven't found anyplace obvious in the code, neither in common code nor
 in the ports' code.

 My question is, is there somewhere these objects are being deleted on
 final shutdown that apparently happens after the leaks are reported,
 or does WebKit have assumptions such as that all still running timers
 must fire before final shutdown that ports such as ours are not
 honoring? (e.g. in my tests garbageCollectSoon() does not end up
 firing the callback because the app shuts down too fast.)

 Thanks,

 Kevin
 ___
 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] Leak reports during shutdown

2009-09-29 Thread Darin Adler
Some leak checkers are based on all objects being deleted at shutdown.  
Those won’t work with WebKit. It doesn’t delete all objects at shutdown.


Other leak checkers are based on finding unreachable objects. Those  
work well with WebKit.


-- Darin

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


Re: [webkit-dev] Leak reports during shutdown

2009-09-29 Thread Kevin Ollivier

Hi Zoltan,

On Sep 29, 2009, at 12:39 PM, Zoltan Herczeg wrote:


Hi Kevin,

WebKit approach is NOT to free memory before quit to make the quit  
process
as fast as possible. The memory manager should free the unfreed  
objects.
However, this approach makes really hard to find the real leaks  
(which

are unreferenced objects).

In my experince the unfreed (non-leak) objects come from several  
sources:

 - JavaScriptCore garbage collector is not called before quit
 - Caches are not cleared before quit
The previous two are performed by QtLauncher in debug mode. See
WebKit/qt/QtLauncher/main.cpp launcherMain()
 - In case of workers, the gc() does not called for each worker  
threads

when the application quits. The JavaScript threads are simply aborted.
 - Global objects are not freed at all. There was an attempt to free  
them
(see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not  
worth

to continue that work, although it helped to find leaks such as this:
https://bugs.webkit.org/show_bug.cgi?id=29295

The remaining unfreed objects are possible leaks. Many of them are
probably port specific (not all port maintainers have resources to  
keep

leak hunters).


Thanks for the detailed response, this makes things very clear! :-) (  
thanks to Darin for his info about leak checkers) I guess I didn't  
really expect things to work this way in debug mode as it seems to me  
RefCountedLeakChecker pretty much needs those resources to be freed in  
order to provide useful leak reports. In any case, I've been thinking  
about adding some APIs to manage the cache to wxWebKit and now I've  
got even more of an incentive to code something up. :-)


Thanks,

Kevin


Zoltan


Hi all,

For a while, ports like wx and Win/Cairo have been seeing various
leaks reported on shutdown, but at least on Mac I've been unable to
see these leaks using memory leak checkers like the one in
Instruments, so I decided to poke into the code a bit more and try to
understand what's going on a bit better.

What I found was that the reported object leaks were pretty much all
related to objects that JSC has references to. Changing
~ScriptController to do a garbageCollectNow() instead of
garbageCollectSoon(), for example, drastically reduced the number of
reported leaks, cleaning up all the CachedResource leaks and almost
all the WebCoreNode leaks. The remaining leaks were almost all
JSC::Structure objects. I've been digging through the code to try and
find the place where these JSC objects are finally deleted, but I
haven't found anyplace obvious in the code, neither in common code  
nor

in the ports' code.

My question is, is there somewhere these objects are being deleted on
final shutdown that apparently happens after the leaks are reported,
or does WebKit have assumptions such as that all still running timers
must fire before final shutdown that ports such as ours are not
honoring? (e.g. in my tests garbageCollectSoon() does not end up
firing the callback because the app shuts down too fast.)

Thanks,

Kevin
___
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