Re: [webkit-dev] Desperate for webkit help

[Scott Thompson]

On Apr 11, 2008, at 7:37 PM, David Kilzer wrote:

The best thing you could do is to file a bug on 
and attach source for a project that reproduces the issue, along  
with details
steps to reproduce the issue.  If you don't have an Apple Developer  
Connection

(ADC) membership, sign up for a free "online" membership using
.


The third thing you COUDLD do is purchase a DTS incident from ADC and  
see if you can engage someone at Apple to help you track down and fix  
your bug.  It will cost you money, but if it helps you fix the bug  
quickly, it can pay for itself.


I don't know about the relationship between DTS and WebKit, but you  
could call ADC and ask.


Scott

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

Re: [webkit-dev] Desperate for webkit help

[David Kilzer]

Hi Mark,

The best thing you could do is to file a bug on 
and attach source for a project that reproduces the issue, along with details
steps to reproduce the issue.  If you don't have an Apple Developer Connection
(ADC) membership, sign up for a free "online" membership using
.

The second thing you should do is to install Wireshark (a packet sniffer) on OS
X and use it to capture the traffic being sent back and forth to the server
when the bug occurs.  (Since this generally requires either GTK built for Cocoa
or X11 to be installed--and using MacPorts or Fink to build it from source--it
may be easier to capture the traffic using "tcpdump" and copying that file to
another platform where you may install a pre-built Wireshark binary.  Hmm...I
guess there is a Wireshark binary for Intel Macs linked off the Downloads page
now.)

http://www.wireshark.org/
http://www.macports.org/
http://fink.sourceforge.net/

I would recommend attaching the tcpdump output to the bug created on
bugreport.apple.com as well.  This is roughly the command you want to run (from
a Terminal) to capture the output on OS X if you don't use Wireshark directly:

sudo tcpdump -s 0 -w packets.tcpdump -i en0

Finally, this kind of sounds like the issue described in this bug on
bugs.webkit.org:

https://bugs.webkit.org/show_bug.cgi?id=5760#c38

If you know enough about the TCP/IP protcol, you should be able to see this
issue happening with the tcpdump packet trace.

Note that the behavior of this keep-alive timeout issue can vary depending on
how "far away" the server is from your client.  I think servers on a local
network (or subnet) display this behavior much easier than hitting a "remote"
server.

Hope that helps!

Dave


Mark <[EMAIL PROTECTED]> wrote:

> Hi. I've been developing a cocoa application based around webkit for the
> last 18 months. It's an auto form filling/submitting tool primarily designed
> for adult webmasters to submit their free pages to link lists. (If this is
> an problem I guess you can stop reading now)...
> Currently development has grinded to a complete hault because of a webkit
> issue that we just can't work round. We first noticed the issue with the
> release of Safari 3 but it still exists in the last nightly build of webkit.
> The issue is this: imagine a simple html form. The form is like so and the
> user filled data is in brackets:
> 
> Name: (mark)
> Email: ([EMAIL PROTECTED])
> Url: (http://www.google.com)
> 
> Now if we submit this form in Safari/Webkit, 40-50% of the time the web
> script will throw up an 'invalid email' or 'invalid url' message. At first
> you think 'oh, I must have entered data incorrectly' but clicking back, data
> looks fine. Submit same data again, second time round it submits fine!
> 
> It seems to happen totally at random, it's like the data visible in the form
> fields (ie, the user entered data) is not being passed onto the form when
> submit is pressed. It worked fine prior to safari 3 and we know it's a
> webkit issue because it only occurs in our app/safari/webkit. Other browsers
> submit the same data perfectly each time to the exact same html forms.
> 
> It's very hard to nail down. Sometimes it will submit fine first time,
> sometimes if it fails first time, it can fail second time and then succeed
> third time. You just have to keep submitting the same data until it works.
> 
> Can anyone please help with this? It's kinda killed our application and as
> the title suggests I'm *desperate* for it to be fixed.
> 
> kindest regards
> 
> mark

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

[webkit-dev] Desperate for webkit help

[Mark]

Hi. I've been developing a cocoa application based around webkit for the
last 18 months. It's an auto form filling/submitting tool primarily designed
for adult webmasters to submit their free pages to link lists. (If this is
an problem I guess you can stop reading now)...
Currently development has grinded to a complete hault because of a webkit
issue that we just can't work round. We first noticed the issue with the
release of Safari 3 but it still exists in the last nightly build of webkit.
The issue is this: imagine a simple html form. The form is like so and the
user filled data is in brackets:

Name: (mark)
Email: ([EMAIL PROTECTED])
Url: (http://www.google.com)

Now if we submit this form in Safari/Webkit, 40-50% of the time the web
script will throw up an 'invalid email' or 'invalid url' message. At first
you think 'oh, I must have entered data incorrectly' but clicking back, data
looks fine. Submit same data again, second time round it submits fine!

It seems to happen totally at random, it's like the data visible in the form
fields (ie, the user entered data) is not being passed onto the form when
submit is pressed. It worked fine prior to safari 3 and we know it's a
webkit issue because it only occurs in our app/safari/webkit. Other browsers
submit the same data perfectly each time to the exact same html forms.

It's very hard to nail down. Sometimes it will submit fine first time,
sometimes if it fails first time, it can fail second time and then succeed
third time. You just have to keep submitting the same data until it works.

Can anyone please help with this? It's kinda killed our application and as
the title suggests I'm *desperate* for it to be fixed.

kindest regards

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

[webkit-dev] KDE Webkit

[Andre-John Mas]

Hi,

I was curious to know what the status of the qtWebkit port was? Also  
once stable can we imagine seeing this as nightly, at least for Linux  
users?


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

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Ryan Leavengood]

On Fri, Apr 11, 2008 at 12:38 PM, David Kilzer <[EMAIL PROTECTED]> wrote:
>
>  In summary, I think it's great to use git for starting a new port, but in the
>  mid- to long-term, I think you'll be better off if there is a bi-directional
>  movement of code between the main svn repository and your port's git
>  repository.  This is basically how Linux kernel development works as
>  well--anyone is free to check out Joe User's git repository, but the overall
>  health of the project benefits when code flows both ways.

OK, I'm convinced. I will say as a "small platform" porter, I
appreciate how many in the WebKit project want the smaller ports
"brought into the fold" of the main project as much as possible.

In regards to the status of my port, we have something working
reasonably well, but the code is currently languishing in my own SVN
repo that is months behind the current WebKit repo. It is also a
partial copy of the repo with only the parts relevant to my port. I
did it this way because that was the best SVN-based workflow I could
come up with at the time But the prospect of merging in months worth
of WebKit changes and the likely pain of that is not appealing, hence
my wanting to move to Git.

Once I get the new Git repo going and figure out a good workflow for
sending those changes back to the main WebKit repo, I will be back in
contact with you guys (probably with some bug reports and patches I
suppose.)

Also I guess at some point I should get commit access to the main repo
to act as the main Haiku port maintainer.

If anyone has any links to documents describing a Git workflow that
posts back to the main WebKit SVN repo I would appreciate it. I know
some of the Apple guys are using Git internally, but I would be
curious to hear more. I'm still far from a Git expert.

Regards,
Ryan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Daniel Zucker]

Hi Ryan,

Thanks for forwarding to the list.  I meant to send it there originally, but
it accidentally got sent only to you.

One additionally point is that by hosting ports with the main webkit trunk
then all ports are treated equally by WebKit policy concerning review,
committers, etc.

For individually hosted Git ports, this is not the case.

Best,
Dan

On Fri, Apr 11, 2008 at 9:37 AM, Ryan Leavengood <[EMAIL PROTECTED]>
wrote:

> Daniel only responded to me personally (the strange way this list
> works I guess), so hopefully he won't mind a public response:
>
> On Fri, Apr 11, 2008 at 12:21 PM, Daniel Zucker <[EMAIL PROTECTED]> wrote:
> > Perhaps one possible negative to this is that there would now be
> definite
> > resource requirements to host a port.  Specifically, a new port would
> need
> > to both host a git server (requiring hardware and bandwidth),
>
> This is a reasonable point, but fortunately there are places like
> http://gitorious.org/ and http://github.com that can host open source
> Git repos for free.
>
> > and also actively migrate patches to this port as they are developed.
>
> True, but *someone* would have to do that work either way, and it is
> probably a better use of resources to have the person with a real
> stake in and understanding of the port doing the work rather than some
> of the other WebKit developers who have deeper concerns in the main
> codebase and the larger ports.
>
> > In the case of ports integrated directly into the main WebKit trunk,
> neither
> > of these are required:  the port code would be hosted at webkit.org, and
> no
> > one needs to actively port patches over since they are maintained in the
> > main webkit trunk.
>
> See above point about maintaining ports.
>
> > Personally, I think the increased resource requirements in the case
> where
> > new ports all have their own git repository would make it difficult for
> > people without a lot of time or money to do new ports.
>
> Time will be required either way, believe you me ;)
>
> Money shouldn't be a big problem because of the above services. Plus
> if a port really becomes that popular it could always be merged back
> into the main repo.
>
> Regards,
> Ryan
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[David Kilzer]

Hi Ryan,

I think this is a great way to manage a nascent port, and I'm glad your
committed to passing platform-agnostic fixes back to the main repository!

One thing I'd like to see is the WebKit wiki updated to list your port (on its
own page), along with basic information about how to access your public
repository.  Actually, if a developer has their own git (or other distributed
SCM) repository, it would be helpful to list them on the wiki as well!

http://trac.webkit.org/projects/webkit/wiki/

In the mid- to long-term, though, you may want to revisit this decision.  I
realize that there is more build breakage for some ports than others.  I'd like
to hear comments from current port maintainers on why that is.  (I think a lot
of it may be due to code refactoring or new features being added, but I think
that's generally a good thing.)

Note that once a given port has a committer, they are free to commit build
fixes with little to no review.  Also, if the port maintainer(s) set up and
maintain their own buildbot server, then project committers know when they've
broken the build and can try to fix it on their own.  (This is especially
beneficial when a large rename commit occurs.)  It's also beneficial to port
the DumpRenderTree test harness so that the port's buildbot may report
regressions.

Finally, I'd add that having more ports in the main repository will cause the
overall design and structure of the code to improve.  Apple was forced to
create platform abstractions when they did the Windows port, and the WxWindows,
Qt, Gtk and non-Apple-Windows ports (among others) have allowed those
abstractions to grow and evolve.  If all of those ports lived purely in
external repositories, the platform abstractions wouldn't be as good, and the
port maintainers would have more work to do and potentially have ugly hacks in
their repositories to get around such limitations.

In summary, I think it's great to use git for starting a new port, but in the
mid- to long-term, I think you'll be better off if there is a bi-directional
movement of code between the main svn repository and your port's git
repository.  This is basically how Linux kernel development works as
well--anyone is free to check out Joe User's git repository, but the overall
health of the project benefits when code flows both ways.

Dave


Ryan Leavengood <[EMAIL PROTECTED]> wrote:

> Hello all,
> 
> I have recently begun to use Git in earnest and after reading various
> things and starting to understand how it works I had an idea: I could
> manage my Haiku WebKit port using Git without ever having my code in
> the "real" WebKit SVN repo. The basic idea would be I would clone the
> current WebKit Git repo, create a branch for my Haiku port, and then
> publish that branch for other Haiku developers to use. This branch
> would never go back into the main WebKit repo. Why would I want to do
> this? Here is what I am thinking:
> 
> - The main WebKit repo would have one less bit of platform code that
> everyone else has to download, even though only a tiny percentage
> would care to use it (as much as I like Haiku at this point it is a
> very small platform.)
> - It would be almost impossible for other people in the WebKit
> community to break the Haiku WebKit build since I (or other Haiku
> developers) would control pulling new changes from the main repo and
> could ensure we fixed problems before publishing those changes to our
> repo.
> - It alleviates other WebKit maintainers from having to be concerned
> about breaking such a tiny port like ours because of the above point.
> - I could freely change my platform code without having to go through
> the strict WebKit review and submit process (which is good in general
> but maybe too heavyweight for my small port.)
> 
> I might also suggest that other smaller ports (*cough* Robert,
> *cough*, AROS) could use this too, but obviously that is up to them.
> 
> The WebKit site can provide links to these platform specific Git repos
> so people can make use of them if they wish.
> 
> I would be curious what the WebKit community thinks about this idea. I
> know the Qt people have been doing this already to some extent with
> their Git repo and I recall this being perceived badly by some. One
> point I would like to make is I would intend to submit any purely
> WebKit-related fixes back to the main repo (which Git makes
> considerably easier than SVN.) So there would not be an issue of
> potentially "good stuff" hiding in my repo (part of what the Qt guys
> got flak for I believe.)
> 
> Regards,
> Ryan

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

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Ryan Leavengood]

Daniel only responded to me personally (the strange way this list
works I guess), so hopefully he won't mind a public response:

On Fri, Apr 11, 2008 at 12:21 PM, Daniel Zucker <[EMAIL PROTECTED]> wrote:
> Perhaps one possible negative to this is that there would now be definite
> resource requirements to host a port.  Specifically, a new port would need
> to both host a git server (requiring hardware and bandwidth),

This is a reasonable point, but fortunately there are places like
http://gitorious.org/ and http://github.com that can host open source
Git repos for free.

> and also actively migrate patches to this port as they are developed.

True, but *someone* would have to do that work either way, and it is
probably a better use of resources to have the person with a real
stake in and understanding of the port doing the work rather than some
of the other WebKit developers who have deeper concerns in the main
codebase and the larger ports.

> In the case of ports integrated directly into the main WebKit trunk, neither
> of these are required:  the port code would be hosted at webkit.org, and no
> one needs to actively port patches over since they are maintained in the
> main webkit trunk.

See above point about maintaining ports.

> Personally, I think the increased resource requirements in the case where
> new ports all have their own git repository would make it difficult for
> people without a lot of time or money to do new ports.

Time will be required either way, believe you me ;)

Money shouldn't be a big problem because of the above services. Plus
if a port really becomes that popular it could always be merged back
into the main repo.

Regards,
Ryan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Ryan Leavengood]

On Fri, Apr 11, 2008 at 11:55 AM, iain <[EMAIL PROTECTED]> wrote:
>
>  This is exactly what I've been doing for my Clutter port. I cloned the
>  official Webkit repo locally, and created an empty git repo on a remote
>  server that I push my changes to. Periodically I pull from the official
>  repo and then push those to my remote one along with any fixes I need to
>  make to the port.

OK nice, I'm glad to hear I'm not crazy with this idea. I had never
heard of Clutter, but it sounds quite cool (man there are so many cool
open source projects out there...but not enough time to play with them
all.)

I think it might be nice to make a sort of "policy" of this for
smaller ports, and have some sort of project infrastructure for it.
Maybe I will create a patch for the web-site to describe this idea and
list the various repos if other people agree this is a good idea for
we smaller ports. Also it might be nice to have a "how to port WebKit"
page based on all our experiences with it.

Regards,
Ryan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] _blank hrefs and new windows

[David Kilzer]

Great!  I just didn't recall seeing that listed before.

Dave


Srinivas Rao M Hamse <[EMAIL PROTECTED]> wrote:

> Hi David,
> 
> There is already a logged bug. Is this not sufficient ?
> 
> http://bugs.webkit.org/show_bug.cgi?id=16562
> 
> 
> regards,
> Srinivas.
> 
> 
> On Fri, Apr 11, 2008 at 7:53 PM, David Kilzer <[EMAIL PROTECTED]> wrote:
> 
> > Artem,
> >
> > Please file a bug on  with a reproducible test
> > case.
> > Thanks!
> >
> > Dave
> >
> >
> > Artem Ananiev <[EMAIL PROTECTED]> wrote:
> >
> > > I have just tried GtkLauncher and it doesn't handle _blank target also.
> > > Thus, it looks like a problem in a shared WebKit code, not specific to
> > > out Java port...
> > >
> > > Thanks,
> > >
> > > Artem
> > >
> > > Artem Ananiev wrote:
> > > > Hi,
> > > >
> > > > I have experienced the following problem with WebKit (Java port). The
> > > > page code is simple:
> > > >
> > > >   Open window
> > > >   Open window
> > > >
> > > > When I right-click on the first link and select 'Open in a new window'
> > > > from context menu, a new window is created and shown - that's fine.
> > > > However, left-click on the first link loads the page 'a.html' in the
> > > > same window - this looks strange to me as the target is _blank.
> > > >
> > > > The second link behaves as expected: it opens a new window with
> > > > left-click and does nothing with right click.
> > > >
> > > > I suppose target="_blank" is handled completely differently than
> > opening
> > > > a new window with a context menu. Is it related to popup blocking and
> > > > different policies in FrameLoaderClient class? Another strange thing
> > is
> > > > that I couldn't find any references to ChromeClient::createWindow()
> > > > method - it is responsible for creating a new window, at least
> > triggered
> > > > from context menu - other than from ContextMenuController...
> > > >
> > > > Thanks,
> > > >
> > > > Artem
> > >
> >
> 
> -- 
> Srinivas Rao M Hamse

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

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[iain]

On Fri, 2008-04-11 at 11:33 -0400, Ryan Leavengood wrote:
> I could
> manage my Haiku WebKit port using Git without ever having my code in
> the "real" WebKit SVN repo. The basic idea would be I would clone the
> current WebKit Git repo, create a branch for my Haiku port, and then
> publish that branch for other Haiku developers to use.

This is exactly what I've been doing for my Clutter port. I cloned the
official Webkit repo locally, and created an empty git repo on a remote
server that I push my changes to. Periodically I pull from the official
repo and then push those to my remote one along with any fixes I need to
make to the port.

iain

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

[webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Ryan Leavengood]

Hello all,

I have recently begun to use Git in earnest and after reading various
things and starting to understand how it works I had an idea: I could
manage my Haiku WebKit port using Git without ever having my code in
the "real" WebKit SVN repo. The basic idea would be I would clone the
current WebKit Git repo, create a branch for my Haiku port, and then
publish that branch for other Haiku developers to use. This branch
would never go back into the main WebKit repo. Why would I want to do
this? Here is what I am thinking:

- The main WebKit repo would have one less bit of platform code that
everyone else has to download, even though only a tiny percentage
would care to use it (as much as I like Haiku at this point it is a
very small platform.)
- It would be almost impossible for other people in the WebKit
community to break the Haiku WebKit build since I (or other Haiku
developers) would control pulling new changes from the main repo and
could ensure we fixed problems before publishing those changes to our
repo.
- It alleviates other WebKit maintainers from having to be concerned
about breaking such a tiny port like ours because of the above point.
- I could freely change my platform code without having to go through
the strict WebKit review and submit process (which is good in general
but maybe too heavyweight for my small port.)

I might also suggest that other smaller ports (*cough* Robert,
*cough*, AROS) could use this too, but obviously that is up to them.

The WebKit site can provide links to these platform specific Git repos
so people can make use of them if they wish.

I would be curious what the WebKit community thinks about this idea. I
know the Qt people have been doing this already to some extent with
their Git repo and I recall this being perceived badly by some. One
point I would like to make is I would intend to submit any purely
WebKit-related fixes back to the main repo (which Git makes
considerably easier than SVN.) So there would not be an issue of
potentially "good stuff" hiding in my repo (part of what the Qt guys
got flak for I believe.)

Regards,
Ryan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] _blank hrefs and new windows

[Srinivas Rao M Hamse]

Hi David,

There is already a logged bug. Is this not sufficient ?

http://bugs.webkit.org/show_bug.cgi?id=16562


regards,
Srinivas.


On Fri, Apr 11, 2008 at 7:53 PM, David Kilzer <[EMAIL PROTECTED]> wrote:

> Artem,
>
> Please file a bug on  with a reproducible test
> case.
> Thanks!
>
> Dave
>
>
> Artem Ananiev <[EMAIL PROTECTED]> wrote:
>
> > I have just tried GtkLauncher and it doesn't handle _blank target also.
> > Thus, it looks like a problem in a shared WebKit code, not specific to
> > out Java port...
> >
> > Thanks,
> >
> > Artem
> >
> > Artem Ananiev wrote:
> > > Hi,
> > >
> > > I have experienced the following problem with WebKit (Java port). The
> > > page code is simple:
> > >
> > >   Open window
> > >   Open window
> > >
> > > When I right-click on the first link and select 'Open in a new window'
> > > from context menu, a new window is created and shown - that's fine.
> > > However, left-click on the first link loads the page 'a.html' in the
> > > same window - this looks strange to me as the target is _blank.
> > >
> > > The second link behaves as expected: it opens a new window with
> > > left-click and does nothing with right click.
> > >
> > > I suppose target="_blank" is handled completely differently than
> opening
> > > a new window with a context menu. Is it related to popup blocking and
> > > different policies in FrameLoaderClient class? Another strange thing
> is
> > > that I couldn't find any references to ChromeClient::createWindow()
> > > method - it is responsible for creating a new window, at least
> triggered
> > > from context menu - other than from ContextMenuController...
> > >
> > > Thanks,
> > >
> > > Artem
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > http://lists.webkit.org/mailman/listinfo/webkit-dev
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Srinivas Rao M Hamse
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] _blank hrefs and new windows

[David Kilzer]

Artem,

Please file a bug on  with a reproducible test case. 
Thanks!

Dave


Artem Ananiev <[EMAIL PROTECTED]> wrote:

> I have just tried GtkLauncher and it doesn't handle _blank target also. 
> Thus, it looks like a problem in a shared WebKit code, not specific to 
> out Java port...
> 
> Thanks,
> 
> Artem
> 
> Artem Ananiev wrote:
> > Hi,
> > 
> > I have experienced the following problem with WebKit (Java port). The 
> > page code is simple:
> > 
> >   Open window
> >   Open window
> > 
> > When I right-click on the first link and select 'Open in a new window' 
> > from context menu, a new window is created and shown - that's fine. 
> > However, left-click on the first link loads the page 'a.html' in the 
> > same window - this looks strange to me as the target is _blank.
> > 
> > The second link behaves as expected: it opens a new window with 
> > left-click and does nothing with right click.
> > 
> > I suppose target="_blank" is handled completely differently than opening 
> > a new window with a context menu. Is it related to popup blocking and 
> > different policies in FrameLoaderClient class? Another strange thing is 
> > that I couldn't find any references to ChromeClient::createWindow() 
> > method - it is responsible for creating a new window, at least triggered 
> > from context menu - other than from ContextMenuController...
> > 
> > Thanks,
> > 
> > Artem
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

Re: [webkit-dev] Webkit with directfb on linux

[Srinivas Rao M Hamse]

Hi Mike,

On Thu, Apr 10, 2008 at 4:17 AM, Mike Emmel <[EMAIL PROTECTED]> wrote:

> I added zoom support into the gtk layer and I have some patches needed
> to build directfb if no X11 is installed some files import X11 still
> mainly the plugin stuff.
>
> Turns out to keep zooming in you have to set min font size to zero.
>
> And yes I have a few different builds for gtk directfb.


 Can i test your Full Page Zooming patches on the latest Webkit Nightlies
for Gtk DirectFB target ?. Please give me the patch file for it.

regards,
Srinivas




>
>
> Mike
>
>
> On Wed, Apr 9, 2008 at 12:33 AM, Srinivas Rao M Hamse
> <[EMAIL PROTECTED]> wrote:
> > Mike,
> >
> >
> > > Finally if your using this for thumbnails I also have so zooming
> patches.
> >
> >
> > What do you mean by zooming patches ?. Is the full page zooming works ?
> Do
> > you have it for Gtk+DirectFB builds ?
> >
> > regards,
> >
> > Srinivas
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 3, 2008 at 11:34 PM, Mike Emmel <[EMAIL PROTECTED]>
> wrote:
> >
> > > Yes if you need help with your setup i.e no X11 I have some patches.
> > > Also I have some pure memory driver patches for DirectFB itself that I
> > > need to push.
> > > Finally if your using this for thumbnails I also have so zooming
> patches.
> > >
> > >
> > >
> > >
> > > On Thu, Apr 3, 2008 at 10:06 AM, Giri Rao <[EMAIL PROTECTED]> wrote:
> > > > Hello,
> > > >
> > > > I was wondering if anyone has successfully built webkit with target
> set
> > to
> > > > directfb (as opposed to X11) on linux.  I have a successful gtk
> build
> > which
> > > > is running fine.  However, I would like to run webkit on a headless
> > linux
> > > > machine hence the question.
> > > >
> > > > Thanks
> > > > Giri
> > > >
> > > > ___
> > > >  webkit-dev mailing list
> > > >  webkit-dev@lists.webkit.org
> > > >  http://lists.webkit.org/mailman/listinfo/webkit-dev
> > > >
> > > >
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > http://lists.webkit.org/mailman/listinfo/webkit-dev
> > >
> >
> >
> >
> > --
> > Srinivas Rao M Hamse
> >
>



-- 
Srinivas Rao M Hamse
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] _blank hrefs and new windows

[Sriram Neelakandan]

Well Gtk Implementation is also incomplete .. Please see this bug ..
http://bugs.webkit.org/show_bug.cgi?id=16562
But even the patch attached here does not work

On Fri, Apr 11, 2008 at 1:59 PM, Artem Ananiev <[EMAIL PROTECTED]>
wrote:

> I have just tried GtkLauncher and it doesn't handle _blank target also.
> Thus, it looks like a problem in a shared WebKit code, not specific to out
> Java port...
>
> Thanks,
>
> Artem
>
>
> Artem Ananiev wrote:
>
> > Hi,
> >
> > I have experienced the following problem with WebKit (Java port). The
> > page code is simple:
> >
> >  Open window
> >  Open window
> >
> > When I right-click on the first link and select 'Open in a new window'
> > from context menu, a new window is created and shown - that's fine. However,
> > left-click on the first link loads the page 'a.html' in the same window -
> > this looks strange to me as the target is _blank.
> >
> > The second link behaves as expected: it opens a new window with
> > left-click and does nothing with right click.
> >
> > I suppose target="_blank" is handled completely differently than opening
> > a new window with a context menu. Is it related to popup blocking and
> > different policies in FrameLoaderClient class? Another strange thing is that
> > I couldn't find any references to ChromeClient::createWindow() method - it
> > is responsible for creating a new window, at least triggered from context
> > menu - other than from ContextMenuController...
> >
> > Thanks,
> >
> > Artem
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Sriram Neelakandan
Author - Embedded Linux System Design And Development (
http://tinyurl.com/2doosu)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Webkit on Qtopia?

[sea]

Hi,

Does anybody know how to build Webkit on Qtopia? Thanks!

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

[webkit-dev] Building the Qt version on Linux

[sea]

Hi,

I am very new to this WebKit technology. I have tried to build Webkit using
Qt.

I have taken the source from WebKit Nightly Builds: "*WebKit
r31787
* was built on 11 April 2008 and is a 8.9 MB download."

I got this building error of libQtWebKit shared library.

tmp/chartables.o:(.rodata+0x0): multiple definition of
`kjs_pcre_default_tables'
tmp/pcre_tables.o:(.rodata+0xa0): first defined here

The error is obvious because JavaScriptCore/pcre/pcre_tables.cpp has
included the generated "C" file (#include "chartables.c")

After commenting out that, build was successful. I just wonder, how that
simple mistake is ignored.

I tried to run Qt Webkit.

./WebKitTools/Scripts/run-webkit-tests --qt

It opens up the main window but I could not browse or do anything with it.
Is this expected? I am pretty interested to help developing WebKit using Qt.
Thanks!


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

Re: [webkit-dev] _blank hrefs and new windows

[Artem Ananiev]

I have just tried GtkLauncher and it doesn't handle _blank target also. 
Thus, it looks like a problem in a shared WebKit code, not specific to 
out Java port...


Thanks,

Artem

Artem Ananiev wrote:

Hi,

I have experienced the following problem with WebKit (Java port). The 
page code is simple:


  Open window
  Open window

When I right-click on the first link and select 'Open in a new window' 
from context menu, a new window is created and shown - that's fine. 
However, left-click on the first link loads the page 'a.html' in the 
same window - this looks strange to me as the target is _blank.


The second link behaves as expected: it opens a new window with 
left-click and does nothing with right click.


I suppose target="_blank" is handled completely differently than opening 
a new window with a context menu. Is it related to popup blocking and 
different policies in FrameLoaderClient class? Another strange thing is 
that I couldn't find any references to ChromeClient::createWindow() 
method - it is responsible for creating a new window, at least triggered 
from context menu - other than from ContextMenuController...


Thanks,

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

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