From guannaixuan at gmail.com  Wed Jan  6 20:21:59 2010
From: guannaixuan at gmail.com (naixuan guan)
Date: Thu, 7 Jan 2010 12:21:59 +0800
Subject: [webkit-qt] Does QtWebKit for Qt/E4.5.0 really support NPAPI?
Message-ID: <cea49fb61001062021u5a3620amf21df1ad69a5dad5@mail.gmail.com>

Hello, everyone~

I have two questions:

1.Does QtWebKit for Qt/E4.5.0 really support NPAPI? I see some code in
PluginViewQt.cpp not implemented.
2.Does NPAPI must need X11 support? Can we realize NPAPI based Qt/Embedded
which don't have X lib but display with framebuffer?

Thanks!

gnx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100107/07021106/attachment.html>

From guannaixuan at gmail.com  Wed Jan  6 20:24:54 2010
From: guannaixuan at gmail.com (naixuan guan)
Date: Thu, 7 Jan 2010 12:24:54 +0800
Subject: [webkit-qt] Does QtWebKit for Qt/E4.5.0 really support NPAPI?
In-Reply-To: <cea49fb61001062021u5a3620amf21df1ad69a5dad5@mail.gmail.com>
References: <cea49fb61001062021u5a3620amf21df1ad69a5dad5@mail.gmail.com>
Message-ID: <cea49fb61001062024m5ef96d24vc660c80f99c1e83c@mail.gmail.com>

sorry , I means Netscape Plugin~(I should not use NPAPI...)

2010/1/7 naixuan guan <guannaixuan at gmail.com>

> Hello, everyone~
>
> I have two questions:
>
> 1.Does QtWebKit for Qt/E4.5.0 really support NPAPI? I see some code in
> PluginViewQt.cpp not implemented.
> 2.Does NPAPI must need X11 support? Can we realize NPAPI based Qt/Embedded
> which don't have X lib but display with framebuffer?
>
> Thanks!
>
> gnx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100107/f9a417d3/attachment.html>

From girish at forwardbias.in  Wed Jan  6 22:37:40 2010
From: girish at forwardbias.in (Girish Ramakrishnan)
Date: Thu, 07 Jan 2010 12:07:40 +0530
Subject: [webkit-qt] Does QtWebKit for Qt/E4.5.0 really support NPAPI?
In-Reply-To: <cea49fb61001062021u5a3620amf21df1ad69a5dad5@mail.gmail.com>
References: <cea49fb61001062021u5a3620amf21df1ad69a5dad5@mail.gmail.com>
Message-ID: <4B458134.4080203@forwardbias.in>

naixuan guan wrote:
> Hello, everyone~
>  
> I have two questions:
>  
> 1.Does QtWebKit for Qt/E4.5.0 really support NPAPI? I see some code in
> PluginViewQt.cpp not implemented.

Yes, most of it works in 4.5.0. But 4.6.0 has much better NPAPI support
for X11.

> 2.Does NPAPI must need X11 support? Can we realize NPAPI based
> Qt/Embedded which don't have X lib but display with framebuffer?

The public NPAPI code in Qt/WebKit for linux requires X11.

For DirectFB, you will have to implement the entire Plugin
infrastructure in Webkit yourself. Same goes for Linux fb. In both
cases, you will also need to somehow get hold of the flash plugin with
support for fb, presumably by contacting Adobe.

Girish

From guannaixuan at gmail.com  Thu Jan  7 17:34:48 2010
From: guannaixuan at gmail.com (naixuan guan)
Date: Fri, 8 Jan 2010 09:34:48 +0800
Subject: [webkit-qt] How does QtWebkit parse this web page?
Message-ID: <cea49fb61001071734x3b46b618ga8f8bd7966893a75@mail.gmail.com>

Hello, everyone!
I met a web page as follow:
<OBJECT id=StormPlayer style="LEFT: 0px; WIDTH: 100%; TOP: 0px; HEIGHT:
100%"
codeBase=http://123.123.123.181:8080/storm.cab#version=3,8,9,7 height=400
width=800 classid=clsid:BDBB259C-9729-484F-BF9D-778149B375B2>
<PARAM NAME="URL" VALUE="?">
<PARAM NAME="ShowUI" VALUE="1">
<PARAM NAME="volume" VALUE="90">
<PARAM NAME="autoPlay" VALUE="2">
<PARAM NAME="mute" VALUE="0">
<PARAM NAME="DropEnable" VALUE="0">
<PARAM NAME="EnableFullScreen" VALUE="0">
<PARAM NAME="ShowVideo" VALUE="1">
<PARAM NAME="loop" VALUE="2">
</OBJECT>
<SCRIPT language=JavaScript>
document.StormPlayer.URL = "abc.def.sds";
</SCRIPT>

now I have create a "Qt based plugin"(based on QWebPluginFactory) for this
"object" tag, but my plugin
could only get the value of "URL" is "?" in the MyPlugin::create() function.
How could I get the url modified by JS in my plugin?
Any suggestion will be appreciate~
Thanks!

gnx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100108/6020088d/attachment.html>

From simon.hausmann at nokia.com  Fri Jan  8 08:40:21 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Fri, 8 Jan 2010 17:40:21 +0100
Subject: [webkit-qt] Sending XMLHttpRequests from pages loaded from
	local URLs to web sites.
In-Reply-To: <A99B171D26E1564B92D36826128CD66159B8870D53@NOK-EUMSG-01.mgdnok.nokia.com>
References: <A99B171D26E1564B92D36826128CD66159B8870D53@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <201001081740.21181.simon.hausmann@nokia.com>


(Kenneth, Benjamin, Tor Arne, others interested in the API - please comment)

On Monday 21 December 2009 Szabo Carol (Nokia-D/Boston), wrote:
> While allowing pages loaded from one security origin to send
>  XMLHttpRequests to URLs located in a different security origin is unsecure
>  for various reasons and therefore should be forbidden by default, there
>  are legitimate use cases such as those of Offline Applications and Widgets
>  that require this feature. WebKit internally supports a static whiteList
>  that pairs source security origins with ranges of allowed target security
>  origins. This whieList is privately exposed by the QtWebKit Api for the
>  use of DumpRenderTree via
> 
> void QWEBKIT_EXPORT qt_drt_whiteListAccessFromOrigin(const QString&
>  sourceOrigin, const QString& destinationProtocol, const QString&
>  destinationHost, bool allowDestinationSubdomains); void QWEBKIT_EXPORT
>  qt_drt_resetOriginAccessWhiteLists();
> 
> Since the need for this Api appears to be broad and long term I suggest
>  making it an official Api. In keeping with other QtWebKit Apis, here is my
>  proposal:

I agree, we should try to make it public API.
 
> In the current QWebSecurity origin add the following members:
> 
> static QWebSecurityOrigin* create(const QUrl&);
>           -- This is needed because all current constructors of
>  QWebSecurity origin are private and none of them takes a Url as an
>  argument. -- Since this pattern is not used in Qt, probably adding a
>  public constructor would be more appropriate. Please vote on this.
> 
> typedef enum
> {
>      DontIncludeSubdomains,
>      IncludeSubdomains
> } SubdomainHandling;
> 
> void addToWhiteList(const QUrl&, SubdomainHandling subdomainHandling =
>  DontIncludeSubdomains); static void clearWhiteLists();
> 
>         -- These functions implement the currently hidden API.
>         -- There is a fine point about addToWhiteList: 
>  qt_drt_whiteListAccessFromOrigin ignores *. at the beginning of the
>  hostname, QUrl does not accept host names containing *. This difference in
>  behavior must be accounted for in DumpRenderTree when making the
>  transition and may be an issue for users, as code like this
>  page->securityOrigin()->addToWhiteList(QUrl(http://*.google.com"),
>  QWebSecurityOrigin::IncludeSubDomains); has the most likely unexpected
>  effect of whitelisting all http websites. an alternative is to use a
>  version of add to whitelist that is closer to the ultimate implementation:
>  void addToWhiteList(const QString& scheme, const QString& host,
>  SubdomainHandling subdomainHandling = DontIncludeSubdomains);

With QUrl not accepting "*" in the host name I think it's clear that it's not 
the right data type to use.

I remember I opposed to a method that has many arguments, initially. But 
looking at the resulting code with a member method I'm inclined to change my 
opinion ;-). Let's compare:

frame->securityOrigin()->addToWhiteList("http", "*.google.com", 
QWebSecurityOrigin::AllowSubDomains);

By looking at the code one might believe that this only affects the security 
origin of the frame, but the call has a global effect!

What about this API?

QWebSecurityOrigin::DomainAccess access;
access.source
access.scheme = "http";
access.domain = "*.google.com";
access.includeSubDomains = true;

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
access);


The alternative remains the big long one, just for comparision:

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
"http", "*.google.com", QWebSecurityOrigin::AllowAccessToSubDomains");


Granted, only few developers will ever write this...

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100108/2d205812/attachment.bin>

From guannaixuan at gmail.com  Mon Jan 11 22:54:20 2010
From: guannaixuan at gmail.com (naixuan guan)
Date: Tue, 12 Jan 2010 14:54:20 +0800
Subject: [webkit-qt] How does QtWebkit parse this web page?
In-Reply-To: <7eb9ad711001080931p6d6b4d21p87180d8d5d6b3bac@mail.gmail.com>
References: <cea49fb61001071734x3b46b618ga8f8bd7966893a75@mail.gmail.com>
	<7eb9ad711001080931p6d6b4d21p87180d8d5d6b3bac@mail.gmail.com>
Message-ID: <cea49fb61001112254m106685bcl97119061ddbf20e@mail.gmail.com>

yes, I try qwebframe::evaluateJavaScript(). But after test, I
found something...

First by reading some docs I know the follow page will call a activeX
plugin.

I rewrite the webpage as follow:

<OBJECT id=StormPlayer style="LEFT: 0px; WIDTH: 100%; TOP: 0px; HEIGHT:
100%"
codeBase=http://123.123.123.181:8080/storm.cab#version=3,8,9,7 height=400
width=800 classid=clsid:BDBB259C-9729-484F-BF9D-778149B375B2>
<PARAM NAME="URL" VALUE="?">
<PARAM NAME="ShowUI" VALUE="1">
<PARAM NAME="volume" VALUE="90">
<PARAM NAME="autoPlay" VALUE="2">
<PARAM NAME="mute" VALUE="0">
<PARAM NAME="DropEnable" VALUE="0">
<PARAM NAME="EnableFullScreen" VALUE="0">
<PARAM NAME="ShowVideo" VALUE="1">
<PARAM NAME="loop" VALUE="2">
</OBJECT>
<SCRIPT language=JavaScript>
alert(document.StormPlayer.URL); //only change this argument
</SCRIPT>
when I use arora(based on QtWebkit) load this page, it alert "undefined".
when I use firefox or IE(not install the activeX plugin), it also alert
"undefined".
when I use IE(with this activeX plugin installed), it alert "?".

so I guess, unless we install this activeX plugin, the browser
will not recognize the param "URL" in this "object" tag, of course we can't
change its value through JS.
By the way, activeX work only on Windows, Is there any way that webkit in
Qt/E could parse this page? or can we rewrite this webpage then we can parse
the url set by JS(because I want to build a player plugin and get the video
data through the url)

Hope anyone give me some tips.

Thanks!

gnx
2010/1/9 tonikitoo (Antonio Gomes) <tonikitoo at gmail.com>

> same results w/ qwebframe::evaluateJavaScript() ?
>
> On Thu, Jan 7, 2010 at 9:34 PM, naixuan guan <guannaixuan at gmail.com>
> wrote:
> > Hello, everyone!
> > I met a web page as follow:
> > <OBJECT id=StormPlayer style="LEFT: 0px; WIDTH: 100%; TOP: 0px; HEIGHT:
> > 100%"
> > codeBase=http://123.123.123.181:8080/storm.cab#version=3,8,9,7height=400
> > width=800 classid=clsid:BDBB259C-9729-484F-BF9D-778149B375B2>
> > <PARAM NAME="URL" VALUE="?">
> > <PARAM NAME="ShowUI" VALUE="1">
> > <PARAM NAME="volume" VALUE="90">
> > <PARAM NAME="autoPlay" VALUE="2">
> > <PARAM NAME="mute" VALUE="0">
> > <PARAM NAME="DropEnable" VALUE="0">
> > <PARAM NAME="EnableFullScreen" VALUE="0">
> > <PARAM NAME="ShowVideo" VALUE="1">
> > <PARAM NAME="loop" VALUE="2">
> > </OBJECT>
> > <SCRIPT language=JavaScript>
> > document.StormPlayer.URL = "abc.def.sds";
> > </SCRIPT>
> >
> > now I have create a "Qt based plugin"(based on QWebPluginFactory) for
> this
> > "object" tag, but my plugin
> > could only get the value of "URL" is "?" in the MyPlugin::create()
> function.
> > How could I get the url modified by JS in my plugin?
> > Any suggestion will be appreciate~
> > Thanks!
> >
> > gnx
> > _______________________________________________
> > webkit-qt mailing list
> > webkit-qt at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> >
> >
>
>
>
> --
> --Antonio Gomes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100112/6e084537/attachment.html>

From henry.haverinen at nokia.com  Wed Jan 13 02:51:13 2010
From: henry.haverinen at nokia.com (henry.haverinen at nokia.com)
Date: Wed, 13 Jan 2010 11:51:13 +0100
Subject: [webkit-qt] Documenting QtWebKit features for the web developer
Message-ID: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>


Hi everyone,

Many people have requested documentation as to which HTML5, CSS3 and other interesting features are supported in QtWebKit. 

So I've started this work by gathering a possible list of relevant features in Qt 4.6.0 for the web developer in this wiki: http://trac.webkit.org/wiki/QtWebKitTableOfFeatures46. 

Questions:
- is this a good level of granularity?
- what's missing?
- what's wrong?

Ideally, we should be able to link to the layout tests or Qt autotests to show whether a certain feature works or not. And once we have good documentation available, we should move it to the official QtWebKit documentation.

Please feel free to add your corrections, additions and comments to the wiki.

Best regards,
Henry


From noam.rosenthal at nokia.com  Wed Jan 13 07:10:19 2010
From: noam.rosenthal at nokia.com (noam.rosenthal at nokia.com)
Date: Wed, 13 Jan 2010 16:10:19 +0100
Subject: [webkit-qt] Documenting QtWebKit features for the web developer
In-Reply-To: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
References: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
Message-ID: <3E1170DEF188104E81C5A1C2CDB207E15577D72461@NOK-EUMSG-01.mgdnok.nokia.com>

Hi Henry,

>-----Original Message-----
>From: webkit-qt-bounces at lists.webkit.org 
>Haverinen Henry (Nokia-D-Qt/Oslo)

>So I've started this work by gathering a possible list of 
>relevant features in Qt 4.6.0 for the web developer in this 
>wiki: http://trac.webkit.org/wiki/QtWebKitTableOfFeatures46. 
>
>Questions:
>- is this a good level of granularity?
>- what's missing?
>- what's wrong?
>

Great initiative, many people were asking for this.
One column that I'd add is "known issues" - sometimes a feature is supported but there are some issues with it.
Another column I'd maybe add is "since" where one could put a change-number when the feature begins to be supported, or a JIRA bug-ID when it's being tracked and worked on.
This will allow people to vote/comment on issues and make this list into something more two-sided :)

Cheers
No'am



From steve.lewontin at nokia.com  Wed Jan 13 07:31:24 2010
From: steve.lewontin at nokia.com (steve.lewontin at nokia.com)
Date: Wed, 13 Jan 2010 16:31:24 +0100
Subject: [webkit-qt] Documenting QtWebKit features for the web developer
In-Reply-To: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
References: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
Message-ID: <4CDA341AFF3A834DAED5591D954288E456DE600C1F@NOK-EUMSG-01.mgdnok.nokia.com>

What do the blank boxes mean? 

-----Original Message-----
From: webkit-qt-bounces at lists.webkit.org [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of Haverinen Henry (Nokia-D-Qt/Oslo)
Sent: Wednesday, January 13, 2010 5:51 AM
To: webkit-qt at lists.webkit.org
Subject: [webkit-qt] Documenting QtWebKit features for the web developer


Hi everyone,

Many people have requested documentation as to which HTML5, CSS3 and other interesting features are supported in QtWebKit. 

So I've started this work by gathering a possible list of relevant features in Qt 4.6.0 for the web developer in this wiki: http://trac.webkit.org/wiki/QtWebKitTableOfFeatures46. 

Questions:
- is this a good level of granularity?
- what's missing?
- what's wrong?

Ideally, we should be able to link to the layout tests or Qt autotests to show whether a certain feature works or not. And once we have good documentation available, we should move it to the official QtWebKit documentation.

Please feel free to add your corrections, additions and comments to the wiki.

Best regards,
Henry

_______________________________________________
webkit-qt mailing list
webkit-qt at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt

From simon.hausmann at nokia.com  Wed Jan 13 07:48:48 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Wed, 13 Jan 2010 16:48:48 +0100
Subject: [webkit-qt] heads up: build system changes
Message-ID: <201001131648.48392.simon.hausmann@nokia.com>

Hi,

Jocelyn has been working on a bigger rework of the build system. See 
https://bugs.webkit.org/show_bug.cgi?id=33542 for details. We plan on landing 
this now.

The main result of the patch is that the generated files are created in a 
separate build step, and only once the files are generated qmake can be called 
on WebCore.pro. The main advantage is that we'll finally get proper 
dependencies for the generated files, for much more reliable incremental builds 
on all platforms.

In practice this won't have any impact on your work if you're using 
WebKitTools/Scripts/build-webkit to build WebKit.

If you're modifying an IDL file you'll have to either use build-webkit to build 
or re-generate the files using "make generated_files".

If you want to build WebKit without the script, then you hvae to use slightly 
different qmake commands.

Old way:

qmake -r
make

New way:

qmake -r DerivedSources.pro
cd JavaScriptCore
make generated_files
cd WebCore
make generated_files
cd WebCore
qmake
make



Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100113/ee4b1afb/attachment.bin>

From henry.haverinen at nokia.com  Wed Jan 13 08:38:39 2010
From: henry.haverinen at nokia.com (henry.haverinen at nokia.com)
Date: Wed, 13 Jan 2010 17:38:39 +0100
Subject: [webkit-qt] Documenting QtWebKit features for the web developer
In-Reply-To: <4CDA341AFF3A834DAED5591D954288E456DE600C1F@NOK-EUMSG-01.mgdnok.nokia.com>
References: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
	<4CDA341AFF3A834DAED5591D954288E456DE600C1F@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <133CA4F02FF95E49B7678172653A6A744F6814DB21@NOK-EUMSG-04.mgdnok.nokia.com>

 

>From: Lewontin Steve (Nokia-D/Boston) 

>What do the blank boxes mean? 

Nothing, the table hasn't really been populated yet. 

Regards,
Henry

From henry.haverinen at nokia.com  Wed Jan 13 08:42:35 2010
From: henry.haverinen at nokia.com (henry.haverinen at nokia.com)
Date: Wed, 13 Jan 2010 17:42:35 +0100
Subject: [webkit-qt] Documenting QtWebKit features for the web developer
In-Reply-To: <3E1170DEF188104E81C5A1C2CDB207E15577D72461@NOK-EUMSG-01.mgdnok.nokia.com>
References: <133CA4F02FF95E49B7678172653A6A744F680ECF34@NOK-EUMSG-04.mgdnok.nokia.com>
	<3E1170DEF188104E81C5A1C2CDB207E15577D72461@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <133CA4F02FF95E49B7678172653A6A744F6814DB24@NOK-EUMSG-04.mgdnok.nokia.com>


>From: Rosenthal Noam (Nokia-D-Qt/RedwoodCity) 

>Great initiative, many people were asking for this.
>One column that I'd add is "known issues" - sometimes a 
>feature is supported but there are some issues with it.
>Another column I'd maybe add is "since" where one could put a 
>change-number when the feature begins to be supported, or a 
>JIRA bug-ID when it's being tracked and worked on.
>This will allow people to vote/comment on issues and make this 
>list into something more two-sided :)

That's a good idea!.

In some cases the known issues could be visible in the layout test results.
If something works perfectly, then there is less need for documentation.
If it works partially, we should probably refer to some objective test results.

Regards,
Henry

From simon.hausmann at nokia.com  Thu Jan 14 03:37:26 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Thu, 14 Jan 2010 12:37:26 +0100
Subject: [webkit-qt] heads up: build system changes
In-Reply-To: <201001131648.48392.simon.hausmann@nokia.com>
References: <201001131648.48392.simon.hausmann@nokia.com>
Message-ID: <201001141237.26679.simon.hausmann@nokia.com>


Yael pointed out that there was an error. Here's a slight correction:

On Wednesday 13 January 2010 Hausmann Simon (Nokia-D-Qt/Oslo), wrote:
[...]
> New way:

Broken way:

> 
> qmake -r DerivedSources.pro
> cd JavaScriptCore
> make generated_files
> cd WebCore
> make generated_files
> cd WebCore
> qmake
> make

Working way:

Generate the stuff first:

qmake -r DerivedSources.pro
cd JavaScriptCore
make -f Makefile.DerivedSources generated_files
cd WebCore
make -f Makefile.DerivedSources generated_files

Then for proper incremental builds (if you're not changing the IDL files, 
etc.):

cd WebCore
qmake
make



Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100114/2fa7b68e/attachment.bin>

From simon.hausmann at nokia.com  Thu Jan 14 06:54:56 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Thu, 14 Jan 2010 15:54:56 +0100
Subject: [webkit-qt] heads up: build system changes
In-Reply-To: <201001141237.26679.simon.hausmann@nokia.com>
References: <201001131648.48392.simon.hausmann@nokia.com>
	<201001141237.26679.simon.hausmann@nokia.com>
Message-ID: <201001141554.56589.simon.hausmann@nokia.com>

On Thursday 14 January 2010 Hausmann Simon (Nokia-D-Qt/Oslo), wrote:
> Yael pointed out that there was an error. Here's a slight correction:
> 
> On Wednesday 13 January 2010 Hausmann Simon (Nokia-D-Qt/Oslo), wrote:
> [...]
> 
> > New way:
> 
> Broken way:
> > qmake -r DerivedSources.pro
> > cd JavaScriptCore
> > make generated_files
> > cd WebCore
> > make generated_files
> > cd WebCore
> > qmake
> > make
> 
> Working way:
> 
> Generate the stuff first:
> 
> qmake -r DerivedSources.pro
> cd JavaScriptCore
> make -f Makefile.DerivedSources generated_files
> cd WebCore
> make -f Makefile.DerivedSources generated_files
> 
> Then for proper incremental builds (if you're not changing the IDL files,
> etc.):
> 
> cd WebCore
> qmake
> make

This way used to be required for Symbian, but build-webkit now provides this 
as a convenience.


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100114/1e2b4c27/attachment.bin>

From laszlo.1.gombos at nokia.com  Fri Jan 15 15:17:36 2010
From: laszlo.1.gombos at nokia.com (laszlo.1.gombos at nokia.com)
Date: Sat, 16 Jan 2010 00:17:36 +0100
Subject: [webkit-qt] Sending XMLHttpRequests from pages loaded
	from	local URLs to web sites.
In-Reply-To: <201001081740.21181.simon.hausmann@nokia.com>
References: <A99B171D26E1564B92D36826128CD66159B8870D53@NOK-EUMSG-01.mgdnok.nokia.com>
	<201001081740.21181.simon.hausmann@nokia.com>
Message-ID: <FFF3EA8D74C64440A0AF2BF3334314E056A9D8698B@NOK-EUMSG-01.mgdnok.nokia.com>

Simon,

Carol & I discus this a bit more. 

"GlobalAccess" in the name is a bit misleading as one might relate it to granting all=global access to something, which is not the case.  I think this API works similarly to globalSettings() interface as it sets up access rules for to-be-created pages. I think this should be a static QWebSecurityOrigin function and static also signals that this is "global".

What about "static QWebSecurityOrigin::addAccessFromOrigin(..).". I do not really have an opinion on the arguments, both proposals (big long one and DomainAccess ) looks good to me.

Laszlo


-----Original Message-----
From: webkit-qt-bounces at lists.webkit.org [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of Hausmann Simon (Nokia-D-Qt/Oslo)
Sent: Friday, January 08, 2010 11:40 AM
To: webkit-qt at lists.webkit.org
Subject: Re: [webkit-qt] Sending XMLHttpRequests from pages loaded from local URLs to web sites.


(Kenneth, Benjamin, Tor Arne, others interested in the API - please comment)

On Monday 21 December 2009 Szabo Carol (Nokia-D/Boston), wrote:
> While allowing pages loaded from one security origin to send  
> XMLHttpRequests to URLs located in a different security origin is 
> unsecure  for various reasons and therefore should be forbidden by 
> default, there  are legitimate use cases such as those of Offline 
> Applications and Widgets  that require this feature. WebKit internally 
> supports a static whiteList  that pairs source security origins with 
> ranges of allowed target security  origins. This whieList is privately 
> exposed by the QtWebKit Api for the  use of DumpRenderTree via
> 
> void QWEBKIT_EXPORT qt_drt_whiteListAccessFromOrigin(const QString&  
> sourceOrigin, const QString& destinationProtocol, const QString&  
> destinationHost, bool allowDestinationSubdomains); void QWEBKIT_EXPORT  
> qt_drt_resetOriginAccessWhiteLists();
> 
> Since the need for this Api appears to be broad and long term I 
> suggest  making it an official Api. In keeping with other QtWebKit 
> Apis, here is my
>  proposal:

I agree, we should try to make it public API.
 
> In the current QWebSecurity origin add the following members:
> 
> static QWebSecurityOrigin* create(const QUrl&);
>           -- This is needed because all current constructors of  
> QWebSecurity origin are private and none of them takes a Url as an  
> argument. -- Since this pattern is not used in Qt, probably adding a  
> public constructor would be more appropriate. Please vote on this.
> 
> typedef enum
> {
>      DontIncludeSubdomains,
>      IncludeSubdomains
> } SubdomainHandling;
> 
> void addToWhiteList(const QUrl&, SubdomainHandling subdomainHandling =  
> DontIncludeSubdomains); static void clearWhiteLists();
> 
>         -- These functions implement the currently hidden API.
>         -- There is a fine point about addToWhiteList: 
>  qt_drt_whiteListAccessFromOrigin ignores *. at the beginning of the  
> hostname, QUrl does not accept host names containing *. This 
> difference in  behavior must be accounted for in DumpRenderTree when 
> making the  transition and may be an issue for users, as code like 
> this  
> page->securityOrigin()->addToWhiteList(QUrl(http://*.google.com"),
>  QWebSecurityOrigin::IncludeSubDomains); has the most likely 
> unexpected  effect of whitelisting all http websites. an alternative 
> is to use a  version of add to whitelist that is closer to the ultimate implementation:
>  void addToWhiteList(const QString& scheme, const QString& host,  
> SubdomainHandling subdomainHandling = DontIncludeSubdomains);

With QUrl not accepting "*" in the host name I think it's clear that it's not the right data type to use.

I remember I opposed to a method that has many arguments, initially. But looking at the resulting code with a member method I'm inclined to change my opinion ;-). Let's compare:

frame->securityOrigin()->addToWhiteList("http", "*.google.com",
QWebSecurityOrigin::AllowSubDomains);

By looking at the code one might believe that this only affects the security 
origin of the frame, but the call has a global effect!

What about this API?

QWebSecurityOrigin::DomainAccess access;
access.source
access.scheme = "http";
access.domain = "*.google.com";
access.includeSubDomains = true;

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
access);


The alternative remains the big long one, just for comparision:

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
"http", "*.google.com", QWebSecurityOrigin::AllowAccessToSubDomains");


Granted, only few developers will ever write this...

Simon

From lists at roberthogan.net  Sun Jan 17 12:41:39 2010
From: lists at roberthogan.net (Robert Hogan)
Date: Sun, 17 Jan 2010 20:41:39 +0000
Subject: [webkit-qt] https://bugs.webkit.org/show_bug.cgi?id=17360
Message-ID: <201001172041.39671.lists@roberthogan.net>


To pass test:

http/tests/loading/text-content-type-with-binary-extension.html

and get around the sort of issue described in:

https://bugs.webkit.org/show_bug.cgi?id=17360

[Summary of bug: ContentType text/plain should be ignored if data is 
binary]

Qt or QtWebKit needs to implement some sort of Content-Type processing, 
maybe that described in:

http://tools.ietf.org/html/draft-abarth-mime-sniff-03#section-4

This manipulation should probably be done under
  case QHttpNetworkReplyPrivate::ReadingHeaderState:
in
  void QHttpNetworkConnectionChannel::receiveReply()
where Qt currently manipulates the content-length headers for gzipped 
responses.

Opening up a page of binary garbage is a common headache for users trying 
to download files so this seems like a worthwhile effort and I'm willing to 
implement the RFC referenced above. Is the Qt HTTP stack the right place? 
Would the patch be accepted?

From tonikitoo at gmail.com  Sun Jan 17 19:42:31 2010
From: tonikitoo at gmail.com (tonikitoo (Antonio Gomes))
Date: Sun, 17 Jan 2010 23:42:31 -0400
Subject: [webkit-qt] QtConnectionObjects not cleaned up for QtOwnership
	objects
In-Reply-To: <6b086b440912151429r4521c518p5dc59abc10bf94fd@mail.gmail.com>
References: <6b086b440912151224i5abe766dmb66088cd4048eed@mail.gmail.com>
	<927d01d20912151404q55a540bep979615d5afecb12@mail.gmail.com>
	<6b086b440912151429r4521c518p5dc59abc10bf94fd@mail.gmail.com>
Message-ID: <7eb9ad711001171942pb764a22m4413b273ab06fa9d@mail.gmail.com>

It does not look bad to me. I'd say please file a bug, upload your
patch, and describe how to check the results.

[cc+ Kent]  Maybe kent could have an input (?)


> We have quite a few QObjects that we are inserting into JavaScript
> using addToJavaScriptWindowObject, however because we have limited
> resources and are creating so many of these objects, we would prefer
> that they are NOT ScriptOwnership objects so that there is not as much
> duplication for each frame. ?This presents a problem when it comes to
> using 'connect' to handle signals. ?Each connect creates a
> QtConnectionObject which references the JSHTMLDocument object. ?The
> QtConnectionObject is never destroyed because the QObject is never
> destroyed, and this prevents most of the objects from being cleaned up
> by the gc when the page is refreshed leading to a significant memory
> leak.
>
> The solution I'm working on essentially makes the QtConnectionObject
> 'script owned' so that it is cleaned up when the script is destroyed:
>
> Index: qt_runtime.cpp
> ===================================================================
> --- qt_runtime.cpp ? ? ?(revision 52150)
> +++ qt_runtime.cpp ? ? ?(working copy)
> @@ -1527,6 +1527,11 @@
> ? ? ? ? ? ? ? ?else {
> ? ? ? ? ? ? ? ? ? ?// Store connection
> ? ? ? ? ? ? ? ? ? ?connections.insert(sender, conn);
> + ? ? ? ? ? ? ? ? ? ?// also create a script wrapper for the
> connection object, but make sure that it is destroyed when
> + ? ? ? ? ? ? ? ? ? ?// the script goes away
> + ? ? ? ? ? ? ? ? ? ?d->m_instance->rootObject()->gcProtect(
> + ? ? ? ? ? ? ? ? ? ? ? QtInstance::getQtInstance(conn,
> d->m_instance->rootObject(), QScriptEngine::ScriptOwnership)->
> +
> createRuntimeObject(exec->dynamicGlobalObject()->globalExec()));
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ?// Now to find our previous connection object. Hmm.
>
> This seems to be working in my limited tests. ?Can anyone comment on
> the validity of this solution?

-- 
--Antonio Gomes

From kent.hansen at nokia.com  Mon Jan 18 05:19:58 2010
From: kent.hansen at nokia.com (Kent Hansen)
Date: Mon, 18 Jan 2010 14:19:58 +0100
Subject: [webkit-qt] QtConnectionObjects not cleaned up for QtOwnership
 objects
In-Reply-To: <7eb9ad711001171942pb764a22m4413b273ab06fa9d@mail.gmail.com>
References: <6b086b440912151224i5abe766dmb66088cd4048eed@mail.gmail.com>	
	<927d01d20912151404q55a540bep979615d5afecb12@mail.gmail.com>	
	<6b086b440912151429r4521c518p5dc59abc10bf94fd@mail.gmail.com>
	<7eb9ad711001171942pb764a22m4413b273ab06fa9d@mail.gmail.com>
Message-ID: <4B545FFE.3060100@nokia.com>

Hi,
I'd like to see a small, compileable example that shows what issue this 
patch is trying to solve, preferably in the form of a test added to the 
QWebFrame autotest (WebKit/qt/tests/qwebframe). Such a test is needed in 
order to upstream the patch anyway.
The first step would be to file a bug, like Antonio suggests.

Regards,
Kent

ext tonikitoo (Antonio Gomes) skrev:
> It does not look bad to me. I'd say please file a bug, upload your
> patch, and describe how to check the results.
>
> [cc+ Kent]  Maybe kent could have an input (?)
>
>
>   
>> We have quite a few QObjects that we are inserting into JavaScript
>> using addToJavaScriptWindowObject, however because we have limited
>> resources and are creating so many of these objects, we would prefer
>> that they are NOT ScriptOwnership objects so that there is not as much
>> duplication for each frame.  This presents a problem when it comes to
>> using 'connect' to handle signals.  Each connect creates a
>> QtConnectionObject which references the JSHTMLDocument object.  The
>> QtConnectionObject is never destroyed because the QObject is never
>> destroyed, and this prevents most of the objects from being cleaned up
>> by the gc when the page is refreshed leading to a significant memory
>> leak.
>>
>> The solution I'm working on essentially makes the QtConnectionObject
>> 'script owned' so that it is cleaned up when the script is destroyed:
>>
>> Index: qt_runtime.cpp
>> ===================================================================
>> --- qt_runtime.cpp      (revision 52150)
>> +++ qt_runtime.cpp      (working copy)
>> @@ -1527,6 +1527,11 @@
>>                else {
>>                    // Store connection
>>                    connections.insert(sender, conn);
>> +                    // also create a script wrapper for the
>> connection object, but make sure that it is destroyed when
>> +                    // the script goes away
>> +                    d->m_instance->rootObject()->gcProtect(
>> +                       QtInstance::getQtInstance(conn,
>> d->m_instance->rootObject(), QScriptEngine::ScriptOwnership)->
>> +
>> createRuntimeObject(exec->dynamicGlobalObject()->globalExec()));
>>                }
>>            } else {
>>                // Now to find our previous connection object. Hmm.
>>
>> This seems to be working in my limited tests.  Can anyone comment on
>> the validity of this solution?
>>     
>
>   


From simon.hausmann at nokia.com  Tue Jan 19 07:17:35 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Tue, 19 Jan 2010 16:17:35 +0100
Subject: [webkit-qt] Sending XMLHttpRequests from pages loaded from
	local URLs to web sites.
In-Reply-To: <FFF3EA8D74C64440A0AF2BF3334314E056A9D8698B@NOK-EUMSG-01.mgdnok.nokia.com>
References: <A99B171D26E1564B92D36826128CD66159B8870D53@NOK-EUMSG-01.mgdnok.nokia.com>
	<201001081740.21181.simon.hausmann@nokia.com>
	<FFF3EA8D74C64440A0AF2BF3334314E056A9D8698B@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <201001191617.39141.simon.hausmann@nokia.com>

On Saturday 16 January 2010 Gombos Laszlo.1 (Nokia-D/Boston), wrote:
> Simon,
> 
> Carol & I discus this a bit more.
> 
> "GlobalAccess" in the name is a bit misleading as one might relate it to
>  granting all=global access to something, which is not the case.  I think
>  this API works similarly to globalSettings() interface as it sets up
>  access rules for to-be-created pages. I think this should be a static
>  QWebSecurityOrigin function and static also signals that this is "global".
> 
> What about "static QWebSecurityOrigin::addAccessFromOrigin(..).". I do not
>  really have an opinion on the arguments, both proposals (big long one and
>  DomainAccess ) looks good to me.

After a long API discussion here in Oslo we concluded a proposal. I pasted it 
into bugzilla at

	https://bugs.webkit.org/show_bug.cgi?id=31875#c11

-- qwebsecurityorigin.h

class QWebSecurityOrigin {
    ...

    class AccessEntry {
    public:
        AccessEntry();
        AccessEntry(const QString& destination);
        ~AccessEntry();

        QString domain() const { return m_domain; }
        void setDomain(const QString& domain) { m_domain = domain; }

        void setScheme(const QString& scheme) const { m_scheme = scheme; }
        QString scheme() const { return m_scheme; }

        void setAllowSubDomains(bool allow) { m_allowSubDomains = allow; }
        bool allowSubDomains() const { return m_allowSubDomains; }

    private:
        QString m_domain;
        QString m_scheme;
        bool m_allowSubDomains;
        struct Private;
        Private *d;
    };

    ...
    static QList<QWebSecurityOrigin::AccessEntry> crossOriginAccessList(const
QString& origin);
    static void setCrossOriginAccessList(const QString& origin, const
QList<QWebSecurityOrigin::AcessEntry>& list);
    static clearCrossOriginAccessLists();
    ...

-- qwebsecurityorigin.cpp

QWebSecurityOrigin::AccessEntry::AcessEntry()
    : m_allowSubDomains(false)
    , d(0)
{
}

QWebSecurityOrigin::AccessEntry::AcessEntry(const QString& destination)
    : m_allowSubDomains(false)
    , d(0)
{
    RefPtr<SecurityOrigin> dest =
SecurityOrigin::createFromString(destination);
    m_domain = dest.host();
    m_scheme = dest.protocol();
}

QWebSecurityOrigin::AccessEntry::~AcessEntry()
{
    delete d;
}

-- example use-cases

QList<QWebSecurityOrigin::AccessEntry> accessList =
QWebSecuritOrigin::crossOriginAccessList("wheatherwidget.com");

for (...) {
    QWebSecurityOrigin::AccessEntry entry;
    entry.setDomain("google.com");
    entry.setAllowSubDomains(true);

    accessList.append(entry);
}

accessList.append(QWebSecurityOrigin::AccessEntry("https://google.com"));

QWebSecurityOrigin::AccessEntry entry("https://google.com");
entry.setAllowSubDomains(true);
accessList.append(entry);

QWebSecurityOrigin::setCrossOriginAccessList("weatherwidget.com", accessList);

QWebSecurityOrigin::clearCrossOriginAccessLists();


Simon

> -----Original Message-----
> From: webkit-qt-bounces at lists.webkit.org
>  [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of Hausmann Simon
>  (Nokia-D-Qt/Oslo) Sent: Friday, January 08, 2010 11:40 AM
> To: webkit-qt at lists.webkit.org
> Subject: Re: [webkit-qt] Sending XMLHttpRequests from pages loaded from
>  local URLs to web sites.
> 
> 
> (Kenneth, Benjamin, Tor Arne, others interested in the API - please
>  comment)
> 
> On Monday 21 December 2009 Szabo Carol (Nokia-D/Boston), wrote:
> > While allowing pages loaded from one security origin to send
> > XMLHttpRequests to URLs located in a different security origin is
> > unsecure  for various reasons and therefore should be forbidden by
> > default, there  are legitimate use cases such as those of Offline
> > Applications and Widgets  that require this feature. WebKit internally
> > supports a static whiteList  that pairs source security origins with
> > ranges of allowed target security  origins. This whieList is privately
> > exposed by the QtWebKit Api for the  use of DumpRenderTree via
> >
> > void QWEBKIT_EXPORT qt_drt_whiteListAccessFromOrigin(const QString&
> > sourceOrigin, const QString& destinationProtocol, const QString&
> > destinationHost, bool allowDestinationSubdomains); void QWEBKIT_EXPORT
> > qt_drt_resetOriginAccessWhiteLists();
> >
> > Since the need for this Api appears to be broad and long term I
> > suggest  making it an official Api. In keeping with other QtWebKit
> > Apis, here is my
> >  proposal:
> 
> I agree, we should try to make it public API.
> 
> > In the current QWebSecurity origin add the following members:
> >
> > static QWebSecurityOrigin* create(const QUrl&);
> >           -- This is needed because all current constructors of
> > QWebSecurity origin are private and none of them takes a Url as an
> > argument. -- Since this pattern is not used in Qt, probably adding a
> > public constructor would be more appropriate. Please vote on this.
> >
> > typedef enum
> > {
> >      DontIncludeSubdomains,
> >      IncludeSubdomains
> > } SubdomainHandling;
> >
> > void addToWhiteList(const QUrl&, SubdomainHandling subdomainHandling =
> > DontIncludeSubdomains); static void clearWhiteLists();
> >
> >         -- These functions implement the currently hidden API.
> >         -- There is a fine point about addToWhiteList:
> >  qt_drt_whiteListAccessFromOrigin ignores *. at the beginning of the
> > hostname, QUrl does not accept host names containing *. This
> > difference in  behavior must be accounted for in DumpRenderTree when
> > making the  transition and may be an issue for users, as code like
> > this
> > page->securityOrigin()->addToWhiteList(QUrl(http://*.google.com"),
> >  QWebSecurityOrigin::IncludeSubDomains); has the most likely
> > unexpected  effect of whitelisting all http websites. an alternative
> > is to use a  version of add to whitelist that is closer to the ultimate
> > implementation: void addToWhiteList(const QString& scheme, const QString&
> > host, SubdomainHandling subdomainHandling = DontIncludeSubdomains);
> 
> With QUrl not accepting "*" in the host name I think it's clear that it's
>  not the right data type to use.
> 
> I remember I opposed to a method that has many arguments, initially. But
>  looking at the resulting code with a member method I'm inclined to change
>  my opinion ;-). Let's compare:
> 
> frame->securityOrigin()->addToWhiteList("http", "*.google.com",
> QWebSecurityOrigin::AllowSubDomains);
> 
> By looking at the code one might believe that this only affects the
>  security origin of the frame, but the call has a global effect!
> 
> What about this API?
> 
> QWebSecurityOrigin::DomainAccess access;
> access.source
> access.scheme = "http";
> access.domain = "*.google.com";
> access.includeSubDomains = true;
> 
> QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80",
> access);
> 
> 
> The alternative remains the big long one, just for comparision:
> 
> QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80",
> "http", "*.google.com", QWebSecurityOrigin::AllowAccessToSubDomains");
> 
> 
> Granted, only few developers will ever write this...
> 
> Simon
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100119/0bcaa957/attachment.bin>

From Yongjun.Zhang at nokia.com  Tue Jan 19 08:38:04 2010
From: Yongjun.Zhang at nokia.com (Yongjun.Zhang at nokia.com)
Date: Tue, 19 Jan 2010 17:38:04 +0100
Subject: [webkit-qt] heads up: build system changes
In-Reply-To: <201001141554.56589.simon.hausmann@nokia.com>
References: <201001131648.48392.simon.hausmann@nokia.com>
	<201001141237.26679.simon.hausmann@nokia.com>
	<201001141554.56589.simon.hausmann@nokia.com>
Message-ID: <3AB7C47FF8799A42900F62F22692C04E55B5276D2F@NOK-EUMSG-01.mgdnok.nokia.com>

Hi,

Did anyone try the new way in mac?

I have qt 4.6.0 in mac.  "qmake -r DerivedSource.pro" generated file DerivedSources.make (not Makefile.DerivedSources) in JavaScriptCore & WebCore, and when I try "make -r DerivedSources.make" it complains "No rule to make target 'ArrayPrototype.lut.h', needed by 'all'".

Thanks,

/ Yongjun


>-----Original Message-----
>From: webkit-qt-bounces at lists.webkit.org 
>[mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of 
>Hausmann Simon (Nokia-D-Qt/Oslo)
>Sent: Thursday, January 14, 2010 9:55 AM
>To: webkit-qt at lists.webkit.org
>Subject: Re: [webkit-qt] heads up: build system changes
>
>On Thursday 14 January 2010 Hausmann Simon (Nokia-D-Qt/Oslo), wrote:
>> Yael pointed out that there was an error. Here's a slight correction:
>> 
>> On Wednesday 13 January 2010 Hausmann Simon (Nokia-D-Qt/Oslo), wrote:
>> [...]
>> 
>> > New way:
>> 
>> Broken way:
>> > qmake -r DerivedSources.pro
>> > cd JavaScriptCore
>> > make generated_files
>> > cd WebCore
>> > make generated_files
>> > cd WebCore
>> > qmake
>> > make
>> 
>> Working way:
>> 
>> Generate the stuff first:
>> 
>> qmake -r DerivedSources.pro
>> cd JavaScriptCore
>> make -f Makefile.DerivedSources generated_files cd WebCore make -f 
>> Makefile.DerivedSources generated_files
>> 
>> Then for proper incremental builds (if you're not changing the IDL 
>> files,
>> etc.):
>> 
>> cd WebCore
>> qmake
>> make
>
>This way used to be required for Symbian, but build-webkit now 
>provides this as a convenience.
>
>
>Simon
>

From tor.arne.vestbo at nokia.com  Wed Jan 20 00:00:10 2010
From: tor.arne.vestbo at nokia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=)
Date: Wed, 20 Jan 2010 09:00:10 +0100
Subject: [webkit-qt] heads up: build system changes
In-Reply-To: <3AB7C47FF8799A42900F62F22692C04E55B5276D2F@NOK-EUMSG-01.mgdnok.nokia.com>
References: <201001131648.48392.simon.hausmann@nokia.com>	<201001141237.26679.simon.hausmann@nokia.com>	<201001141554.56589.simon.hausmann@nokia.com>
	<3AB7C47FF8799A42900F62F22692C04E55B5276D2F@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <hj6d69$vtq$1@ger.gmane.org>

Yongjun.Zhang at nokia.com wrote:
> Hi,
> 
> Did anyone try the new way in mac?
> 
> I have qt 4.6.0 in mac.  "qmake -r DerivedSource.pro" generated file
> DerivedSources.make (not Makefile.DerivedSources) in JavaScriptCore &
> WebCore, and when I try "make -r DerivedSources.make" it complains
> "No rule to make target 'ArrayPrototype.lut.h', needed by 'all'".

build-webkit works fine here, creating a Makefile.DerivedSources, but 
that's because it passes -o Makefile.DerivedSources to qmake.

You also want to pass the target "generated_files" when running make.

Try that, or use build-webkit directly.

tor arne


From carol.szabo at nokia.com  Wed Jan 20 10:50:08 2010
From: carol.szabo at nokia.com (carol.szabo at nokia.com)
Date: Wed, 20 Jan 2010 19:50:08 +0100
Subject: [webkit-qt] Sending XMLHttpRequests from pages loaded from
 local URLs to web sites
In-Reply-To: <mailman.19.1263999608.30899.webkit-qt@lists.webkit.org>
References: <mailman.19.1263999608.30899.webkit-qt@lists.webkit.org>
Message-ID: <A99B171D26E1564B92D36826128CD66159B8E5869B@NOK-EUMSG-01.mgdnok.nokia.com>

I am pasting here the reply I made to Simon's comment on bugs.webkit.org:

I hope you guys realize that this interface cannot be implemented (except in a
hackish way) as a thin wrapper over existing WebCore functionality because
webkit supports a write only API for whitelists.
The WebCore/page/OriginAccessEntry and SecurityOrigin classes will need to be
enriched with code implementing the supporting functionality for this API, or
otherwise duplicate copies need to be kept for the lists associated with every
origin until they are removed.
Also, the crossOriginAccessList function involves returning by value a
structure of significant complexity, which usually involves a lot of copying
and reallocating memory, not a brilliant idea in my opinion, even when the list
is usually small and the function is rarely called.
I suggest changing the crossOriginAccessList function to return a smart pointer
of some kind to the whiteList and adding a constructor to the AccessEntry that
would construct it based on parts retrieved from the WebCore OriginAccessEntry:
scheme, domain, allow subdomains.
If we are to make changes to WebCore, I would argue for adding a port field to
the access entry structure since the SecurityOrigin is also defined by the port
in addition to the host and security.
You realize that in your example with allowSubDomains=false www.google.com
would not be included, as what is called domain, when allowSubDomains is false,
really means virtual host at list for HTTP, that is why I am not sure how to
call this field that has dual meaning.

Before jumping into implementing this thing, I want to test that this is what we really want.
TO put it in exact and simple terms my concerns are:
1. Do we want to enrich the WebCore whitelist support to help us implementing this API correctly?
2. Do we want to return the OriginAccessList by value or by pointer?
3. Do we want to add support for including the port in the Access permission criteria?
4. Shall we continue to call the AccessEntry field domain or is securityDomain any better?

Thanks
Carol Szabo
Nokia Inc.


After a long API discussion here in Oslo we concluded a proposal. I pasted it 
into bugzilla at

	https://bugs.webkit.org/show_bug.cgi?id=31875#c11

-- qwebsecurityorigin.h

class QWebSecurityOrigin {
    ...

    class AccessEntry {
    public:
        AccessEntry();
        AccessEntry(const QString& destination);
        ~AccessEntry();

        QString domain() const { return m_domain; }
        void setDomain(const QString& domain) { m_domain = domain; }

        void setScheme(const QString& scheme) const { m_scheme = scheme; }
        QString scheme() const { return m_scheme; }

        void setAllowSubDomains(bool allow) { m_allowSubDomains = allow; }
        bool allowSubDomains() const { return m_allowSubDomains; }

    private:
        QString m_domain;
        QString m_scheme;
        bool m_allowSubDomains;
        struct Private;
        Private *d;
    };

    ...
    static QList<QWebSecurityOrigin::AccessEntry> crossOriginAccessList(const
QString& origin);
    static void setCrossOriginAccessList(const QString& origin, const
QList<QWebSecurityOrigin::AcessEntry>& list);
    static clearCrossOriginAccessLists();
    ...

-- qwebsecurityorigin.cpp

QWebSecurityOrigin::AccessEntry::AcessEntry()
    : m_allowSubDomains(false)
    , d(0)
{
}

QWebSecurityOrigin::AccessEntry::AcessEntry(const QString& destination)
    : m_allowSubDomains(false)
    , d(0)
{
    RefPtr<SecurityOrigin> dest =
SecurityOrigin::createFromString(destination);
    m_domain = dest.host();
    m_scheme = dest.protocol();
}

QWebSecurityOrigin::AccessEntry::~AcessEntry()
{
    delete d;
}

-- example use-cases

QList<QWebSecurityOrigin::AccessEntry> accessList =
QWebSecuritOrigin::crossOriginAccessList("wheatherwidget.com");

for (...) {
    QWebSecurityOrigin::AccessEntry entry;
    entry.setDomain("google.com");
    entry.setAllowSubDomains(true);

    accessList.append(entry);
}

accessList.append(QWebSecurityOrigin::AccessEntry("https://google.com"));

QWebSecurityOrigin::AccessEntry entry("https://google.com");
entry.setAllowSubDomains(true);
accessList.append(entry);

QWebSecurityOrigin::setCrossOriginAccessList("weatherwidget.com", accessList);

QWebSecurityOrigin::clearCrossOriginAccessLists();


Simon


From ariya.hidayat at gmail.com  Sat Jan 23 09:48:24 2010
From: ariya.hidayat at gmail.com (Ariya Hidayat)
Date: Sat, 23 Jan 2010 09:48:24 -0800
Subject: [webkit-qt] stand-alone JS interpreter
Message-ID: <ba035dd11001230948v2c7ff71dr738ef47356f74c5e@mail.gmail.com>

Usually I can build the stand-alone JS interpreter by doing: cd
JavaScriptCore && qmake && make

However, since http://trac.webkit.org/changeset/53187, I can't do it
anymore. Since I got no clue about the build system, any hints on how
to build JS interpreter for the Qt port?

From loki at inf.u-szeged.hu  Sat Jan 23 10:22:21 2010
From: loki at inf.u-szeged.hu (Gabor Loki)
Date: Sat, 23 Jan 2010 19:22:21 +0100
Subject: [webkit-qt] stand-alone JS interpreter
In-Reply-To: <ba035dd11001230948v2c7ff71dr738ef47356f74c5e@mail.gmail.com>
References: <ba035dd11001230948v2c7ff71dr738ef47356f74c5e@mail.gmail.com>
Message-ID: <1264270941.7060.15.camel@alga-box>

Hi Ariya,

Ariya Hidayat wrote:
> Usually I can build the stand-alone JS interpreter by doing: cd
> JavaScriptCore && qmake && make

Is the 'jsc' binary what you mean?
Well, Simon wrote a draft about the new building method:

> Working way:
> 
> Generate the stuff first:
> 
> qmake -r DerivedSources.pro
> cd JavaScriptCore
> make -f Makefile.DerivedSources generated_files
> cd WebCore
> make -f Makefile.DerivedSources generated_files
> 
> Then for proper incremental builds (if you're not changing the IDL
> files, 
> etc.):
> 
> cd WebCore
> qmake
> make
> 

Anyway, I have a script to build only the 'jsc' binary. See at:
http://gist.github.com/284711

If you want to use the interpreter (instead of JIT) you should
pass DEFINES+=ENABLE_JIT=0 and DEFINES+=ENABLE_YARR=0 to the
script.

--Gabor



From ariya.hidayat at gmail.com  Sat Jan 23 11:33:39 2010
From: ariya.hidayat at gmail.com (Ariya Hidayat)
Date: Sat, 23 Jan 2010 11:33:39 -0800
Subject: [webkit-qt] stand-alone JS interpreter
In-Reply-To: <1264270941.7060.15.camel@alga-box>
References: <ba035dd11001230948v2c7ff71dr738ef47356f74c5e@mail.gmail.com>
	<1264270941.7060.15.camel@alga-box>
Message-ID: <ba035dd11001231133lb9c716ax56fe31f7bd027d84@mail.gmail.com>

> Anyway, I have a script to build only the 'jsc' binary. See at:
> http://gist.github.com/284711

Thank you for the script!

From ariya.hidayat at gmail.com  Sat Jan 23 11:36:40 2010
From: ariya.hidayat at gmail.com (Ariya Hidayat)
Date: Sat, 23 Jan 2010 11:36:40 -0800
Subject: [webkit-qt] Qt JSC ARM test hardware
Message-ID: <ba035dd11001231136rba09d56gb665a92459c84d97@mail.gmail.com>

Hi good people,

This is mainly for the Szeged folks: for the benchmark shown
http://www.sed.hu/webkit/, for Linux/ARM/Qt, what is test hardware for
this? Is it still Nokia N8xx? If yes, do you guys have plan to include
faster TI OMAP platform such as what is used in e.g. BeagleBoard or
Gumstix? I can imagine that N900 will be a good contender as well :)

Thank you!


-- 
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat

From loki at inf.u-szeged.hu  Sat Jan 23 12:32:44 2010
From: loki at inf.u-szeged.hu (Gabor Loki)
Date: Sat, 23 Jan 2010 21:32:44 +0100
Subject: [webkit-qt] Qt JSC ARM test hardware
In-Reply-To: <ba035dd11001231136rba09d56gb665a92459c84d97@mail.gmail.com>
References: <ba035dd11001231136rba09d56gb665a92459c84d97@mail.gmail.com>
Message-ID: <1264278764.7060.34.camel@alga-box>

Hi Ariya,

Ariya Hidayat wrote:
> This is mainly for the Szeged folks: for the benchmark shown
> http://www.sed.hu/webkit/, for Linux/ARM/Qt, what is test hardware for
> this? Is it still Nokia N8xx? If yes, do you guys have plan to include
> faster TI OMAP platform such as what is used in e.g. BeagleBoard or
> Gumstix? I can imagine that N900 will be a good contender as well :)

Fortunately, we have a better device for this purpose. The N8xx
and N900 are not very suitable for benchmarking. Currently the
benchmark runs on a dedicated Cortex-A8 board with 512 Mb memory.
In additional, we are going to set up a similar board for ARM-Qt
buildbot as well. We are almost there to show it. ;)

--Gabor



From ariya.hidayat at gmail.com  Sat Jan 23 16:54:04 2010
From: ariya.hidayat at gmail.com (Ariya Hidayat)
Date: Sat, 23 Jan 2010 16:54:04 -0800
Subject: [webkit-qt] Qt JSC ARM test hardware
In-Reply-To: <1264278764.7060.34.camel@alga-box>
References: <ba035dd11001231136rba09d56gb665a92459c84d97@mail.gmail.com>
	<1264278764.7060.34.camel@alga-box>
Message-ID: <ba035dd11001231654x68dd2259o5d26bd03581d4f79@mail.gmail.com>

> Fortunately, we have a better device for this purpose. The N8xx
> and N900 are not very suitable for benchmarking. Currently the
> benchmark runs on a dedicated Cortex-A8 board with 512 Mb memory.
> In additional, we are going to set up a similar board for ARM-Qt
> buildbot as well. We are almost there to show it. ;)

Hi Gabor, thanks for the info.

Maybe time to update http://www.sed.hu/webkit/?page=techdetails with
this information? Probably along with detailed descriptions of
processor speed and family model, would be lovely to those who are
into ARM hacking :)



-- 
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat

From loki at inf.u-szeged.hu  Sat Jan 23 23:48:44 2010
From: loki at inf.u-szeged.hu (Gabor Loki)
Date: Sun, 24 Jan 2010 08:48:44 +0100
Subject: [webkit-qt] Qt JSC ARM test hardware
In-Reply-To: <ba035dd11001231654x68dd2259o5d26bd03581d4f79@mail.gmail.com>
References: <ba035dd11001231136rba09d56gb665a92459c84d97@mail.gmail.com>
	<1264278764.7060.34.camel@alga-box>
	<ba035dd11001231654x68dd2259o5d26bd03581d4f79@mail.gmail.com>
Message-ID: <1264319324.2622.10.camel@alga-box>

Ariya Hidayat wrote:
> Maybe time to update http://www.sed.hu/webkit/?page=techdetails with
> this information? Probably along with detailed descriptions of
> processor speed and family model, would be lovely to those who are
> into ARM hacking :)

You are right ;). I will update the Technical details page.
BTW, We are going to cut-off those pages. The new benchmark
is set up on our blog space as well.
See at http://webkit.sed.hu/benchmark

--Gabor



From simon.hausmann at nokia.com  Thu Jan 28 07:53:31 2010
From: simon.hausmann at nokia.com (Simon Hausmann)
Date: Thu, 28 Jan 2010 16:53:31 +0100
Subject: [webkit-qt] library linkage
Message-ID: <201001281653.31651.simon.hausmann@nokia.com>

Hi,

we used to build JavaScriptCore as a static library and then link it into 
QtWebKit and JSC. We had to stop doing that because with qmake that static 
linkage propagated to the applications, causing them who link against QtWebKit 
to also try to link against the static library.

With Qt 4.6.0 this was fixed in qmake through the introduction of the 
PRIVATE_LIBS variable, which can be used to link libraries that should not be 
visible to the libs/apps that link against the library that is being created.

I've done a quick prototype hack to verify that this works, and indeed it does 
(patch attached).

Nowadays there are a few arguments in favour of separating the two again, one 
of them being for example the option of applying different optimization flags 
for JavaScriptCore than for the rest.


If anyone feels tempted to mess a bit with the build system, please feel free 
to pick up this task :). I'd be happy to help with the review.


Simon
-------------- next part --------------
diff --git a/JavaScriptCore/JavaScriptCore.pri b/JavaScriptCore/JavaScriptCore.pri
index 75737ae..d9039bc 100644
--- a/JavaScriptCore/JavaScriptCore.pri
+++ b/JavaScriptCore/JavaScriptCore.pri
@@ -40,6 +40,10 @@ INCLUDEPATH = \
     $$JSC_GENERATED_SOURCES_DIR \
     $$INCLUDEPATH
 
+linux-*: DEFINES += HAVE_STDINT_H
+freebsd-*: DEFINES += HAVE_PTHREAD_NP_H
+win32-*: DEFINES += _HAS_TR1=0
+
 DEFINES += BUILDING_QT__ BUILDING_JavaScriptCore BUILDING_WTF
 
 win32-* {
diff --git a/JavaScriptCore/JavaScriptCore.pro b/JavaScriptCore/JavaScriptCore.pro
index 0d6becb..fe3a58e 100644
--- a/JavaScriptCore/JavaScriptCore.pro
+++ b/JavaScriptCore/JavaScriptCore.pro
@@ -10,40 +10,18 @@ CONFIG += depend_includepath
 
 contains(QT_CONFIG, embedded):CONFIG += embedded
 
-CONFIG(QTDIR_build) {
-    GENERATED_SOURCES_DIR = $$PWD/generated
-    OLDDESTDIR = $$DESTDIR
-    include($$QT_SOURCE_TREE/src/qbase.pri)
-    INSTALLS =
-    DESTDIR = $$OLDDESTDIR
-    DEFINES *= NDEBUG
-}
-
-isEmpty(GENERATED_SOURCES_DIR):GENERATED_SOURCES_DIR = tmp
-GENERATED_SOURCES_DIR_SLASH = $${GENERATED_SOURCES_DIR}$${QMAKE_DIR_SEP}
-
-INCLUDEPATH += $$GENERATED_SOURCES_DIR
-
 !CONFIG(QTDIR_build) {
-    CONFIG(debug, debug|release) {
-        OBJECTS_DIR = obj/debug
-    } else { # Release
-        OBJECTS_DIR = obj/release
-    }
+    DESTDIR = $$OUTPUT_DIR/lib
+    !static: DEFINES += QT_MAKEDLL
 }
 
-CONFIG(release):!CONFIG(QTDIR_build) {
+CONFIG(release):!CONFIG(standalone_package) {
     contains(QT_CONFIG, reduce_exports):CONFIG += hide_symbols
     unix:contains(QT_CONFIG, reduce_relocations):CONFIG += bsymbolic_functions
 }
 
-linux-*: DEFINES += HAVE_STDINT_H
-freebsd-*: DEFINES += HAVE_PTHREAD_NP_H
-
 DEFINES += BUILD_WEBKIT
 
-win32-*: DEFINES += _HAS_TR1=0
-
 # Pick up 3rdparty libraries from INCLUDE/LIB just like with MSVC
 win32-g++ {
     TMPPATH            = $$quote($$(INCLUDE))
diff --git a/WebCore/WebCore.pro b/WebCore/WebCore.pro
index 7f630ed..52eaaf7 100644
--- a/WebCore/WebCore.pro
+++ b/WebCore/WebCore.pro
@@ -84,9 +84,6 @@ CONFIG(release):!CONFIG(standalone_package) {
     unix:contains(QT_CONFIG, reduce_relocations):CONFIG += bsymbolic_functions
 }
 
-linux-*: DEFINES += HAVE_STDINT_H
-freebsd-*: DEFINES += HAVE_PTHREAD_NP_H
-
 DEFINES += BUILD_WEBKIT
 
 # Remove whole program optimizations due to miscompilations
@@ -95,7 +92,6 @@ win32-msvc2005|win32-msvc2008:{
     QMAKE_CXXFLAGS_RELEASE -= -GL
 }
 
-win32-*: DEFINES += _HAS_TR1=0
 wince* {
 #    DEFINES += ENABLE_SVG=0 ENABLE_XPATH=0 ENABLE_XBL=0 \
 #               ENABLE_SVG_ANIMATION=0 ENABLE_SVG_USE=0  \
@@ -125,7 +121,32 @@ RESOURCES += \
     RESOURCES += $$PWD/../WebCore/inspector/front-end/WebKit.qrc
 }
 
-include($$PWD/../JavaScriptCore/JavaScriptCore.pri)
+JSPATH = ../JavaScriptCore
+
+INCLUDEPATH = \
+    $$JSPATH \
+    $$JSPATH/.. \
+    $$JSPATH/assembler \
+    $$JSPATH/bytecode \
+    $$JSPATH/bytecompiler \
+    $$JSPATH/debugger \
+    $$JSPATH/interpreter \
+    $$JSPATH/jit \
+    $$JSPATH/parser \
+    $$JSPATH/pcre \
+    $$JSPATH/profiler \
+    $$JSPATH/runtime \
+    $$JSPATH/wrec \
+    $$JSPATH/wtf \
+    $$JSPATH/wtf/unicode \
+    $$JSPATH/yarr \
+    $$JSPATH/API \
+    $$JSPATH/ForwardingHeaders \
+    $$JSPATH/generated \
+    $$INCLUDEPATH
+
+QMAKE_LIBDIR = $$OUTPUT_DIR/lib $$QMAKE_LIBDIR
+LIBS_PRIVATE += -lJavaScriptCore
 
 # Disable HTML5 media compilation if phonon is unavailable
 !contains(DEFINES, ENABLE_VIDEO=1) {
diff --git a/WebKit.pro b/WebKit.pro
index f63eaa0..096b6ac 100644
--- a/WebKit.pro
+++ b/WebKit.pro
@@ -4,6 +4,7 @@ CONFIG += ordered
 include(WebKit.pri)
 
 SUBDIRS += \
+        JavaScriptCore \
         WebCore \
         WebKitTools/QtLauncher \
         WebKit/qt/QGVLauncher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100128/9f3b5c8d/attachment.bin>

From mcygogo at gmail.com  Thu Jan 28 22:13:00 2010
From: mcygogo at gmail.com (michael young)
Date: Fri, 29 Jan 2010 14:13:00 +0800
Subject: [webkit-qt] why the NPAPI cannot work with QtWebKit??
Message-ID: <b85736241001282213x64d4ec0exf351371e0a4cb77e@mail.gmail.com>

the plugin is got from
mozilla-1.9.2/modules/plugin/sdk/samples/basic/unix/ , it's
the Basic Demo of NPAPI,
it's work well in firefox, and google's Chrome, but it cannot work in
QtWebkit. When I run the Demo test page , I got some infomation from
terminal, see below.

** (<unknown>:3020): DEBUG: NP_Initialize
** (<unknown>:3020): DEBUG: NP_Initialize succeeded
** (<unknown>:3020): DEBUG: NP_Initialize
** (<unknown>:3020): DEBUG: NP_Initialize succeeded
** (<unknown>:3020): DEBUG: NP_Initialize
** (<unknown>:3020): DEBUG: NP_Initialize succeeded
** (<unknown>:3020): DEBUG: NP_Initialize
** (<unknown>:3020): DEBUG: NP_Initialize succeeded

So I think the plugin should be working, but in the browser of QtWebkit ,
I nerver get the plugin window, which I can see in the FireFox or Chrome.
So I guess that there should do some change for the npapi plugin of QtWebKit,
but I don't know how,
the Demo's resource is from:
http://mxr.mozilla.org/seamonkey/source/modules/plugin/tools/sdk/samples/basic/unix/

From girish at forwardbias.in  Thu Jan 28 23:02:46 2010
From: girish at forwardbias.in (Girish Ramakrishnan)
Date: Fri, 29 Jan 2010 12:32:46 +0530
Subject: [webkit-qt] why the NPAPI cannot work with QtWebKit??
In-Reply-To: <b85736241001282213x64d4ec0exf351371e0a4cb77e@mail.gmail.com>
References: <b85736241001282213x64d4ec0exf351371e0a4cb77e@mail.gmail.com>
Message-ID: <4B628816.4060001@forwardbias.in>

Hi,

michael young wrote:
> the plugin is got from
> mozilla-1.9.2/modules/plugin/sdk/samples/basic/unix/ , it's
> the Basic Demo of NPAPI,
> it's work well in firefox, and google's Chrome, but it cannot work in
> QtWebkit. When I run the Demo test page , I got some infomation from
> terminal, see below.
> 
> ** (<unknown>:3020): DEBUG: NP_Initialize
> ** (<unknown>:3020): DEBUG: NP_Initialize succeeded
> ** (<unknown>:3020): DEBUG: NP_Initialize
> ** (<unknown>:3020): DEBUG: NP_Initialize succeeded
> ** (<unknown>:3020): DEBUG: NP_Initialize
> ** (<unknown>:3020): DEBUG: NP_Initialize succeeded
> ** (<unknown>:3020): DEBUG: NP_Initialize
> ** (<unknown>:3020): DEBUG: NP_Initialize succeeded
> 
> So I think the plugin should be working, but in the browser of QtWebkit ,
> I nerver get the plugin window, which I can see in the FireFox or Chrome.
> So I guess that there should do some change for the npapi plugin of QtWebKit,
> but I don't know how,
> the Demo's resource is from:
> http://mxr.mozilla.org/seamonkey/source/modules/plugin/tools/sdk/samples/basic/unix/

The NPAPI is very toolkit dependent. It looks like the sample uses Xt.
Qt's event loop and Xt's don't mix. If you make the plugin gtk based, it
will work.

Girish