Re: [webkit-dev] Plugin Questions
On Apr 9, 2008, at 11:19 PM, SON SEOK BAE wrote:
If I want to show contents (for example, Flash animations) with
WebKit port, what kind of flash player plugings should I install for
webkit?
I mean, will it be Flash player for Safari or Flash player for
Firefox or something else?
And are they really pluggable and working well with WebKit ports?
(I just don't understand why there are different pluggins for
Safari and Firefox even though they use the same plugin interface --
NPAPI.)
The plugins are designed based on the platform, not based on the
BrowserEngine.
Whether the BrowserEngine is Safari or Mozilla or Netscape, the same plugin
should work if both the plugin and the BrowserEngine have followed the
Netscape Gecko NPAPI standards.
Just that there are certain rules for various platforms.
MS WINDOWS :
-- plugins subdirectory, should be the same directory as the browser
application
-- plugin should have its own installer to modify the windows registry keys
-- Plug-ins must have a 8.3 filename beginning with NP and ending with
.DLL
MacOS:
-- On the Mac OS platform, the Plug-ins folder is located in the same folder
as the browser application.
-- Plug-ins are identified by file type NSPL.When the browser starts up, it
searches subfolders of the Plug-ins folder for plug-ins and follows aliases
to folders and NSPL files.
-- Plug-in filenames must begin with NP
-- The MIME types supported by a plug-in are determined by its resources.
Unix:
-- On Unix, the plugins directory is set by the environment variable
${MOZILLA_FIVE_HOME}/plugins.
-- Plug-in filenames must begin with NP and ends with .so
-- To determine the MIME types of the plug-ins, the browser loads each
plug-in library and calls its required NPP_GetMIMEDescription entry point.
Do correct me in case i have mentioned anything wrong.
--Priyanka
On Tue, Apr 15, 2008 at 2:36 AM, [EMAIL PROTECTED]
wrote:
Send webkit-dev mailing list submissions to
webkit-dev@lists.webkit.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webkit.org/mailman/listinfo/webkit-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of webkit-dev digest...
Today's Topics:
1. Re: Plugin Questions (Darin Adler)
2. Re: Regarding HashSet (Darin Adler)
3. Re: Patch for compilation error while building with gcc4.x
compilers on latest nightlies (David Kilzer)
4. Re: KDE Webkit (Darin Adler)
5. Re: Patch for compilation error while building with gcc 4.x
compilers on latest nightlies (Darin Adler)
6. Re: Re: Adding Javascript object to Webkit (Geoffrey Garen)
7. Re: Adding Javascript object to Webkit (Mark Rowe)
--
Message: 1
Date: Mon, 14 Apr 2008 08:56:19 -0700
From: Darin Adler [EMAIL PROTECTED]
Subject: Re: [webkit-dev] Plugin Questions
To: SON SEOK BAE [EMAIL PROTECTED]
Cc: webkit-dev webkit-dev@lists.webkit.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
On Apr 9, 2008, at 11:19 PM, SON SEOK BAE wrote:
If I want to show contents (for example, Flash animations) with
WebKit port, what kind of flash player plugings should I install for
webkit?
I mean, will it be Flash player for Safari or Flash player for
Firefox or something else?
And are they really pluggable and working well with WebKit ports?
(I just don't understand why there are different pluggins for
Safari and Firefox even though they use the same plugin interface --
NPAPI.)
There are not different plug-ins for Safari and Firefox on Windows.
Netscape-style plug-ins like Flash work in both browsers.
I don't know what the answer is on Linux.
Sorry I didn't answer all three of your questions, but that's the
answer to the first.
-- Darin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.webkit.org/pipermail/webkit-dev/attachments/20080414/e3b7327b/attachment-0001.html
--
Message: 2
Date: Mon, 14 Apr 2008 09:02:52 -0700
From: Darin Adler [EMAIL PROTECTED]
Subject: Re: [webkit-dev] Regarding HashSet
To: priyanka gupta [EMAIL PROTECTED]
Cc: webkit-dev@lists.webkit.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Apr 9, 2008, at 4:01 AM, priyanka gupta wrote:
I am new to Webkit, but in our project we are using Webkit 3.0 drop
for application development.
Is there any documentation available for proper usage of Hashset
template and its member functions??
Sorry, there is not.
I've been thinking of writing some documentation about how to work
with HashSet and HashMap but this is the first request I've seen for it.
Note that HashSet is
Re: [webkit-dev] Patch for compilation error while building with gcc 4.x compilers on latest nightlies
Thanks Darin David for inputs.
Patches for review should go in bugs.webkit.org, but I think it's worth
mentioning a couple problems I see immediately.
This incorrectly removes the protected for non-GCC compilers and in fact
may not even compile there because __GNUC__ is not defined and there's no
check of it. And the check here says 4, which means the protected is
included only for GCC 5 and newer.
-- Darin
I have logged this issue here:
https://bugs.webkit.org/show_bug.cgi?id=18507
Please review the attached patch file contents:
--- a/WebKit-r31848/JavaScriptCore/kjs/nodes.h 2008-04-12
04:28:00.0 +0530
+++ b/WebKit-r31848/JavaScriptCore/kjs/nodes.h 2008-04-14
19:04:26.0 +0530
@@ -207,7 +207,9 @@
// Used to optimize those nodes that do extra work when returning a
result, even if the result has no semantic relevance
virtual void optimizeForUnnecessaryResult() { }
+#if !COMPILER(GCC) || (COMPILER(GCC) __GNUC__ = 4)
protected:
+#endif
typedef enum { EvalOperator, FunctionCall } CallerType;
template CallerType, bool inline JSValue*
resolveAndCall(ExecState*, const Identifier, ArgumentsNode*, size_t = 0);
};
regards,
Srinivas Rao. M
--
Srinivas Rao M Hamse http://msrinirao.blogspot.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Document's content type
Hi, is there any way to find the content type of the Document? I see two methods - doctype() and realDocType() - in WebCore::Document, however they always return NULL (at least for HTML documents)... Thanks, Artem ___ 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
Hi David,
Do you have any updates on this bug
(#16562http://bugs.webkit.org/show_bug.cgi?id=16562)?
When do we get the working version of this feature ?
regards,
Srinivas Rao. M
On Fri, Apr 11, 2008 at 9:27 PM, David Kilzer [EMAIL PROTECTED] wrote:
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 https://bugs.webkit.org/ 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:
a href=a.html target=_blankOpen window/a
a href=javascript:window.open('a.html', '_blank')Open
window/a
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
--
Srinivas Rao M Hamse
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] landscape mode in gtk port
hi, iam interested in a landscape implementation for the webkit/gtk port. i see few approaches - use the webkit-transform rotate. however as i understand the transform does not affect the layout and hence this may not be useful (e.g. the height/width would remain same for the page) - control the orientation at the gtk window level for the page - did not find such api exists in gtk - change all the relevant components (rendering engine, views, event handlers etc) to understand the new mode of drawing similar to current zoom implementation. Appreciate any advise on how to go about this. thanks, Zaheer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
RE: Re: [webkit-dev] Plugin Questions
Thanks Darin and Priyanka!
I didn't know that Firefox and Safari share the plugin programs before.
(Well, I thought they were not exactly the same, even though they were pretty
similar..)
Why did I think like that? Well..
For example, Flash player..
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlashP2_Platform=Win32P3_Browser=Netscape
It mentioned Firefox, Mozilla, Netscape, Opera, but it didn't mention Safari...
And in the below link..
http://www.adobe.com/shockwave/download/alternates/
There are no downloadable plugins for both Safari and Firefox..
And Gecko(Firefox layout engine) supports 3 types of installation methods --
one of them provides installtions APIs (such as initInstall, performInstall,
etc, but webkit doesn't seem to support those APIs..
So, I thought Safari (Webkit) supports the diffent way of installation method.
Those are the reason why I concluded that Safari and Firefox (or WebKit and
Gecko) didn't share the plugins.
But, surpringly to me, they share the same plugins in real. :)
Thanks again!
Seokbae
-원본 메시지-
보낸 사람: priyanka gupta [EMAIL PROTECTED]
보낸 날짜: 2008-04-15 오후 3:27:12
받는 사람: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
참조: [EMAIL PROTECTED] [EMAIL PROTECTED]
제목: Re: [webkit-dev] Plugin Questions
On Apr 9, 2008, at 11:19 PM, SON SEOK BAE wrote:
If I want to show contents (for example, Flash animations) with
WebKit port, what kind of flash player plugings should I install for
webkit?
I mean, will it be Flash player for Safari or Flash player for
Firefox or something else?
And are they really pluggable and working well with WebKit ports?
(I just don't understand why there are different pluggins for
Safari and Firefox even though they use the same plugin interface --
NPAPI.)
The plugins are designed based on the platform, not based on the BrowserEngine.
Whether the BrowserEngine is Safari or Mozilla or Netscape, the same plugin
should work if both the plugin and the BrowserEngine have followed the
Netscape Gecko NPAPI standards.
Just that there are certain rules for various platforms.
MS WINDOWS :
-- plugins subdirectory, should be the same directory as the browser application
-- plugin should have its own installer to modify the windows registry keys
-- Plug-ins must have a 8.3 filename beginning with NP and ending with .DLL
MacOS:
-- On the Mac OS platform, the Plug-ins folder is located in the same folder as
the browser application.
-- Plug-ins are identified by file type NSPL.When the browser starts up, it
searches subfolders of the Plug-ins folder for plug-ins and follows aliases to
folders and NSPL files.
-- Plug-in filenames must begin with NP
-- The MIME types supported by a plug-in are determined by its resources.
Unix:
-- On Unix, the plugins directory is set by the environment variable
${MOZILLA_FIVE_HOME}/plugins.
-- Plug-in filenames must begin with NP and ends with .so
-- To determine the MIME types of the plug-ins, the browser loads each plug-in
library and calls its required NPP_GetMIMEDescription entry point.
Do correct me in case i have mentioned anything wrong.
--Priyanka
On Tue, Apr 15, 2008 at 2:36 AM, [EMAIL PROTECTED] wrote:
Send webkit-dev mailing list submissions to
webkit-dev@lists.webkit.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webkit.org/mailman/listinfo/webkit-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of webkit-dev digest...
Today's Topics:
1. Re: Plugin Questions (Darin Adler)
2. Re: Regarding HashSet (Darin Adler)
3. Re: Patch for compilation error while building with gcc4.x
compilers on latest nightlies (David Kilzer)
4. Re: KDE Webkit (Darin Adler)
5. Re: Patch for compilation error while building with gcc 4.x
compilers on latest nightlies (Darin Adler)
6. Re: Re: Adding Javascript object to Webkit (Geoffrey Garen)
7. Re: Adding Javascript object to Webkit (Mark Rowe)
--
Message: 1
Date: Mon, 14 Apr 2008 08:56:19 -0700
From: Darin Adler [EMAIL PROTECTED]
Subject: Re: [webkit-dev] Plugin Questions
To: SON SEOK BAE [EMAIL PROTECTED]
Cc: webkit-dev webkit-dev@lists.webkit.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
On Apr 9, 2008, at 11:19 PM, SON SEOK BAE wrote:
If I want to show contents (for example, Flash animations) with
WebKit port, what kind of flash player plugings should I install for
webkit?
I mean, will it be Flash player for Safari or Flash player for
Firefox or something else?
And are they really pluggable and working well with WebKit ports?
(I just don't understand why there are different pluggins for
Safari and Firefox even though they use the
[webkit-dev] IconDatabase and dispatchDidReceiveIcon()
Hi, I'm implementing Frame's icon support in Java port of WebKit. Actually, icons support only include two things: ability to get icon's URL and notification about this URL is ready for the page. The former is easy: I just call iconURL() for the given FrameLoader. However, the latter is not so trivial... I have found some notification in FrameLoaderClient class - dispatchDidReceiveIcon - but it is never called. After some time searching forums I found a post about this notification be dependent on IconDatabase, which is missing in Java port. So the question is: are there any other ways to get a notification about Frame's icon URL is ready? I don't need an icon itself, URL is enough as all the further loading is done in Java code. Thanks, Artem ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Helper actions in Webkit
Sriram Neelakandan wrote: Hi all, I know webkit support NPAPI plugin framework. but what about helper actions ? Invoking an external application based on the MIME TYPE. Is that left to the browser implementation or is it part of the Webkit engine ? WebKit delegates this responsibility to the application. -[WebPolicyDelegate webView:decidePolicyForMIMEType:request:frame:decisionListener:] is the call the application can use to invoke a helper application. See http://developer.apple.com/documentation/Cocoa/Reference/WebKit/Protocols/WebPolicyDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/webView:decidePolicyForMIMEType:request:frame:decisionListener: for details. -Adam ___ 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
Hi Srinivas,
Everything I know is in the bug report. I don't work on the GTK port, so I
don't really have any further insight to share (other than there's a patch
waiting for review on the bug).
Have you tried applying the patch to see if it fixes the issue on your local
tree?
Dave
Srinivas Rao M Hamse [EMAIL PROTECTED] wrote:
Hi David,
Do you have any updates on this bug
(#16562http://bugs.webkit.org/show_bug.cgi?id=16562)?
When do we get the working version of this feature ?
regards,
Srinivas Rao. M
On Fri, Apr 11, 2008 at 9:27 PM, David Kilzer [EMAIL PROTECTED] wrote:
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 https://bugs.webkit.org/ 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:
a href=a.html target=_blankOpen window/a
a href=javascript:window.open('a.html', '_blank')Open
window/a
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
--
Srinivas Rao M Hamse
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] IconDatabase and dispatchDidReceiveIcon()
The notification is truly about the icon itself being ready, not the URL. And yes, it is dependent on the IconDatabase. Currently, if the IconDatabase is not enabled, we never download site icons. If all you care about is the URL, you can grab it and start downloading the icon anytime after the head element is finished parsing. ~Brady On Apr 15, 2008, at 4:54 AM, Artem Ananiev wrote: Hi, I'm implementing Frame's icon support in Java port of WebKit. Actually, icons support only include two things: ability to get icon's URL and notification about this URL is ready for the page. The former is easy: I just call iconURL() for the given FrameLoader. However, the latter is not so trivial... I have found some notification in FrameLoaderClient class - dispatchDidReceiveIcon - but it is never called. After some time searching forums I found a post about this notification be dependent on IconDatabase, which is missing in Java port. So the question is: are there any other ways to get a notification about Frame's icon URL is ready? I don't need an icon itself, URL is enough as all the further loading is done in Java code. 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
Re: [webkit-dev] Document's content type
On Apr 15, 2008, at 12:25 AM, Artem Ananiev wrote: Hi, is there any way to find the content type of the Document? I see two methods - doctype() and realDocType() - in WebCore::Document, however they always return NULL (at least for HTML documents)... These would give the doctype declaration, not the content type (which is sent as part of the http protocol). The content type is stored in the ResourceResponse, I believe we keep around the original response for a document but I don't recall where off-hand. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Desperate for webkit help
The issue appears to be that when WebKit sent a multipart/form-data boundary with a + character in it, the server-side software wouldn't decode the request properly. (When there was no + character in the form boundary, everything worked fine.) Mark didn't say what software he was using on the server side to decode the HTML form data, but it probably requires a simple update to fix the issue. Dave Mark [EMAIL PROTECTED] wrote: Hi guys, many thanks for your advice. I'll check out the wireshark thing for sure. In the meantime I have managed to cobble together a demo so you can see hopefully the bug: Please go here: http://demo.jmbsoft.com/cgi-bin/ags/submit.cgi Enter the following information: Username, Password: Leave Blank Name:, Nickname: Whatever Email: [EMAIL PROTECTED] Description: Enter a 30-40 character string wwerewr ewr Gallery URL: http://www.intotheflood.com/webkit-demo/index.html Category: Leave as is Number of Thumbs: 12 Preview Thumb: choose Let the script select an image from your gallery Now hit submit, it will either throw up a success(submission recorded) or invalid message. If you get success, hit back on your browser, webkit should remember all the information you entered, submit again and again and eventually you should land upon an invalid URL or Invalid email message. I'd be really interested to know if this does indeed happen for you! You may need to submit a lot of times before you get the error, or you may get it straight away. many thanks mark On Sat, Apr 12, 2008 at 1:37 AM, David Kilzer [EMAIL PROTECTED] wrote: Hi Mark, The best thing you could do is to file a bug on https://bugreport.apple.com/ 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 https://connect.apple.com/. 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
Re: [webkit-dev] Desperate for webkit help
I don't have access to the script, but I can get the source. The problem is this form demo from jmbsoft is installed of thousands of thousands of sites that my software needs to submit to, and thus since this webkit bug was introduced my software has real problems with all these sites. All these forms worked fine prior to safari 3 Who do I gotta pay to fix the bug :) On Wed, Apr 16, 2008 at 12:21 AM, David Kilzer [EMAIL PROTECTED] wrote: The issue appears to be that when WebKit sent a multipart/form-data boundary with a + character in it, the server-side software wouldn't decode the request properly. (When there was no + character in the form boundary, everything worked fine.) Mark didn't say what software he was using on the server side to decode the HTML form data, but it probably requires a simple update to fix the issue. Dave Mark [EMAIL PROTECTED] wrote: Hi guys, many thanks for your advice. I'll check out the wireshark thing for sure. In the meantime I have managed to cobble together a demo so you can see hopefully the bug: Please go here: http://demo.jmbsoft.com/cgi-bin/ags/submit.cgi Enter the following information: Username, Password: Leave Blank Name:, Nickname: Whatever Email: [EMAIL PROTECTED] Description: Enter a 30-40 character string wwerewr ewr Gallery URL: http://www.intotheflood.com/webkit-demo/index.html Category: Leave as is Number of Thumbs: 12 Preview Thumb: choose Let the script select an image from your gallery Now hit submit, it will either throw up a success(submission recorded) or invalid message. If you get success, hit back on your browser, webkit should remember all the information you entered, submit again and again and eventually you should land upon an invalid URL or Invalid email message. I'd be really interested to know if this does indeed happen for you! You may need to submit a lot of times before you get the error, or you may get it straight away. many thanks mark On Sat, Apr 12, 2008 at 1:37 AM, David Kilzer [EMAIL PROTECTED] wrote: Hi Mark, The best thing you could do is to file a bug on https://bugreport.apple.com/ 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 https://connect.apple.com/. 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
Re: [webkit-dev] Desperate for webkit help
Mark, You should test my theory (it's only a theory at this point) to make sure it's correct before you assume that you'll have to update the script thousands of web sites. If it is a bug in the script, perhaps you should take the opportunity to devise a way to push out future updates in case you have to upgrade the script again in the future. :) Dave Mark [EMAIL PROTECTED] wrote: I don't have access to the script, but I can get the source. The problem is this form demo from jmbsoft is installed of thousands of thousands of sites that my software needs to submit to, and thus since this webkit bug was introduced my software has real problems with all these sites. All these forms worked fine prior to safari 3 Who do I gotta pay to fix the bug :) On Wed, Apr 16, 2008 at 12:21 AM, David Kilzer [EMAIL PROTECTED] wrote: The issue appears to be that when WebKit sent a multipart/form-data boundary with a + character in it, the server-side software wouldn't decode the request properly. (When there was no + character in the form boundary, everything worked fine.) Mark didn't say what software he was using on the server side to decode the HTML form data, but it probably requires a simple update to fix the issue. Dave Mark [EMAIL PROTECTED] wrote: Hi guys, many thanks for your advice. I'll check out the wireshark thing for sure. In the meantime I have managed to cobble together a demo so you can see hopefully the bug: Please go here: http://demo.jmbsoft.com/cgi-bin/ags/submit.cgi Enter the following information: Username, Password: Leave Blank Name:, Nickname: Whatever Email: [EMAIL PROTECTED] Description: Enter a 30-40 character string wwerewr ewr Gallery URL: http://www.intotheflood.com/webkit-demo/index.html Category: Leave as is Number of Thumbs: 12 Preview Thumb: choose Let the script select an image from your gallery Now hit submit, it will either throw up a success(submission recorded) or invalid message. If you get success, hit back on your browser, webkit should remember all the information you entered, submit again and again and eventually you should land upon an invalid URL or Invalid email message. I'd be really interested to know if this does indeed happen for you! You may need to submit a lot of times before you get the error, or you may get it straight away. many thanks mark On Sat, Apr 12, 2008 at 1:37 AM, David Kilzer [EMAIL PROTECTED] wrote: Hi Mark, The best thing you could do is to file a bug on https://bugreport.apple.com/ 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 https://connect.apple.com/. 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
