Re: [webkit-dev] IconDatabase and dispatchDidReceiveIcon()
Hi, Brady, Brady Eidson wrote: 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. I will process the URL in dispatchDidLoadMainResource then - at this moment is should be definitely available :) Thanks, Artem 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 ___ 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,
Have you tried applying the patch to see if it fixes the issue on your local
tree?
First of all the patch file was not compatible with the latest
nightlies(r31848). Hence i manually applied the those hunks that were
failing to respective files. I could compile and build GtkLauncher. I was
unable to open any new window/popup when i click on the following href links
html
body
HTML version
a href=a.html target=_blankOpen window/a
br
Javascript version
a href=javascript:window.open('a.html', '_blank')Open window/a
/body
/html
On the console i got the following error messages, This came only for the
first time:
for HTML Version i got :
UNIMPLEMENTED:
(../WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:770 virtual
WebCore::Frame* WebKit::FrameLoaderClient::dispatchCreatePage())
UNIMPLEMENTED:
(../WebCore/page/gtk/EventHandlerGtk.cpp:85 bool
WebCore::EventHandler::eventActivatedView(const
WebCore::PlatformMouseEvent) const)
for JavaScript Version I got:
UNIMPLEMENTED:
(../WebKit/gtk/webkit/webkitwebview.cpp:488 void
webkit_web_view_real_window_object_cleared(WebKitWebView*, WebKitWebFrame*,
OpaqueJSContext*, OpaqueJSValue*))
UNIMPLEMENTED:
(../WebCore/platform/gtk/PlatformScreenGtk.cpp:73 WebCore::FloatRect
WebCore::screenAvailableRect(WebCore::Widget*))
UNIMPLEMENTED:
(../WebKit/gtk/webkit/webkitwebview.cpp:481 WebKitWebView*
webkit_web_view_real_create_web_view(WebKitWebView*))
is there a way to get this patch working on the latest builds ?
regards,
Srinivas Rao. M
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
--
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
Re: [webkit-dev] _blank hrefs and new windows
is there a way to get this patch working on the latest builds ?
Please add these comments to the bug itself. Perhaps the author of the patch
will revise it for a later revision.
Dave
Srinivas Rao M Hamse [EMAIL PROTECTED] wrote:
Hi David,
Have you tried applying the patch to see if it fixes the issue on your local
tree?
First of all the patch file was not compatible with the latest
nightlies(r31848). Hence i manually applied the those hunks that were
failing to respective files. I could compile and build GtkLauncher. I was
unable to open any new window/popup when i click on the following href links
html
body
HTML version
a href=a.html target=_blankOpen window/a
br
Javascript version
a href=javascript:window.open('a.html', '_blank')Open window/a
/body
/html
On the console i got the following error messages, This came only for the
first time:
for HTML Version i got :
UNIMPLEMENTED:
(../WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:770 virtual
WebCore::Frame* WebKit::FrameLoaderClient::dispatchCreatePage())
UNIMPLEMENTED:
(../WebCore/page/gtk/EventHandlerGtk.cpp:85 bool
WebCore::EventHandler::eventActivatedView(const
WebCore::PlatformMouseEvent) const)
for JavaScript Version I got:
UNIMPLEMENTED:
(../WebKit/gtk/webkit/webkitwebview.cpp:488 void
webkit_web_view_real_window_object_cleared(WebKitWebView*, WebKitWebFrame*,
OpaqueJSContext*, OpaqueJSValue*))
UNIMPLEMENTED:
(../WebCore/platform/gtk/PlatformScreenGtk.cpp:73 WebCore::FloatRect
WebCore::screenAvailableRect(WebCore::Widget*))
UNIMPLEMENTED:
(../WebKit/gtk/webkit/webkitwebview.cpp:481 WebKitWebView*
webkit_web_view_real_create_web_view(WebKitWebView*))
is there a way to get this patch working on the latest builds ?
regards,
Srinivas Rao. M
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
--
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
Re: [webkit-dev] Desperate for webkit help
The bug is in the php tool, not in webkit. From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) : boundary := 0*69bchars bcharsnospace bchars := bcharsnospace / bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / + / _ / , / - / . / / / : / = / ? '+' is absolutely allowable, I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries. Perhaps what we really want here is a method of specifying the multipart boundary to webkit... and so allow all manner of hackers to work around parsing issues like this one without encouraging people to write crappy parsers. or, you could grab the webkit source, hack a work-around and ship your own webkit dylib embedded in your app. Let's not go tooling with code that works on millions of people's machines because of a fault in code that works on thousands of people's machines. _Mark On Apr 15, 2008, at 4:28 PM, Mark 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!
Re: [webkit-dev] Desperate for webkit help
It used to be worse! At one time we originally allowed all the legal values for base64 encoding in the boundary string: http://trac.webkit.org/projects/webkit/changeset/20074 But then it was changed: https://bugs.webkit.org/show_bug.cgi?id=13352 http://trac.webkit.org/projects/webkit/changeset/22013 And a related change: http://trac.webkit.org/projects/webkit/changeset/20136 Dave Mark Pauley [EMAIL PROTECTED] wrote: The bug is in the php tool, not in webkit. From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) : boundary := 0*69bchars bcharsnospace bchars := bcharsnospace / bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / + / _ / , / - / . / / / : / = / ? '+' is absolutely allowable, I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries. Perhaps what we really want here is a method of specifying the multipart boundary to webkit... and so allow all manner of hackers to work around parsing issues like this one without encouraging people to write crappy parsers. or, you could grab the webkit source, hack a work-around and ship your own webkit dylib embedded in your app. Let's not go tooling with code that works on millions of people's machines because of a fault in code that works on thousands of people's machines. _Mark On Apr 15, 2008, at 4:28 PM, Mark 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
Re: [webkit-dev] Desperate for webkit help
I should have probably said I don't actually code myself. I merely design the software so I'll have to pass on all this information to my coder as some of it is a bit above my head.. What I don't understand is, is the fault is with the script somehow. Why did the exact same scripts work perfectly prior to safari 3? Also, every other browser on window/mac doesn't have this issue. The developer who created the script (jmbsoft) is no longer updating it but it still has a large installed base like I said. thanks for you help guys On Wed, Apr 16, 2008 at 6:32 PM, Mark Pauley [EMAIL PROTECTED] wrote: The bug is in the php tool, not in webkit. From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html): boundary := 0*69bchars bcharsnospace bchars := bcharsnospace / bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / + / _ / , / - / . / / / : / = / ? '+' is absolutely allowable, I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries. Perhaps what we really want here is a method of specifying the multipart boundary to webkit... and so allow all manner of hackers to work around parsing issues like this one without encouraging people to write crappy parsers. or, you could grab the webkit source, hack a work-around and ship your own webkit dylib embedded in your app. Let's not go tooling with code that works on millions of people's machines because of a fault in code that works on thousands of people's machines. _Mark On Apr 15, 2008, at 4:28 PM, Mark 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
Re: [webkit-dev] Desperate for webkit help
Before Safari 3, the boundary string was always: --0xKhTmLbOuNdArY This apparently doesn't violate any assumptions made by the scripts you use. As for other browsers, you'd have to test them yourself, but apparently they never use + characters in their multipart/form-data boundaries. Dave Mark [EMAIL PROTECTED] wrote: I should have probably said I don't actually code myself. I merely design the software so I'll have to pass on all this information to my coder as some of it is a bit above my head.. What I don't understand is, is the fault is with the script somehow. Why did the exact same scripts work perfectly prior to safari 3? Also, every other browser on window/mac doesn't have this issue. The developer who created the script (jmbsoft) is no longer updating it but it still has a large installed base like I said. thanks for you help guys On Wed, Apr 16, 2008 at 6:32 PM, Mark Pauley [EMAIL PROTECTED] wrote: The bug is in the php tool, not in webkit. From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html): boundary := 0*69bchars bcharsnospace bchars := bcharsnospace / bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / + / _ / , / - / . / / / : / = / ? '+' is absolutely allowable, I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries. Perhaps what we really want here is a method of specifying the multipart boundary to webkit... and so allow all manner of hackers to work around parsing issues like this one without encouraging people to write crappy parsers. or, you could grab the webkit source, hack a work-around and ship your own webkit dylib embedded in your app. Let's not go tooling with code that works on millions of people's machines because of a fault in code that works on thousands of people's machines. _Mark On Apr 15, 2008, at 4:28 PM, Mark 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
Re: [webkit-dev] Desperate for webkit help
Hi Mark, On Apr 16, 2008, at 10:32 AM, Mark Pauley wrote: The bug is in the php tool, not in webkit. From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) : boundary := 0*69bchars bcharsnospace bchars := bcharsnospace / bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / + / _ / , / - / . / / / : / = / ? '+' is absolutely allowable, I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries. Perhaps what we really want here is a method of specifying the multipart boundary to webkit... and so allow all manner of hackers to work around parsing issues like this one without encouraging people to write crappy parsers. or, you could grab the webkit source, hack a work-around and ship your own webkit dylib embedded in your app. Let's not go tooling with code that works on millions of people's machines because of a fault in code that works on thousands of people's machines. You are correct by the letter of the spec that + is allowed in the boundary separator. However, this is not the first time we've had a site break in WebKit-based browsers when it worked fine in other browsers, due to our choice of boundary characters. Even though the spec allows a wide character set, I think it would be wise to limit the characters we use to those sent by other browsers, since some web developers develop against IE/Firefox and test against Safari as an afterthought, if at all. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Acid 3
Hi! Just installed Webkit r31915 for Windows, must of the time I get a perfect result on my MacBook (no problems on test 26). So, what is left to be fixed before the webkit team announces a full path? kind regards peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: Acid 3
forgot to add the screenshoot 2008/4/16, Peter Neumayr [EMAIL PROTECTED]: Hi! Just installed Webkit r31915 for Windows, must of the time I get a perfect result on my MacBook (no problems on test 26). So, what is left to be fixed before the webkit team announces a full path? kind regards peter attachment: acid3.png___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: Acid 3
Sorry for the typos, I meant pass instead of path and most instead of must 2008/4/16, Peter Neumayr [EMAIL PROTECTED]: Hi! Just installed Webkit r31915 for Windows, must of the time I get a perfect result on my MacBook (no problems on test 26). So, what is left to be fixed before the webkit team announces a full path? kind regards peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Changes related to canvas
This is a heads up to let people know that the way canvas draws is going to be changing soon. Right now canvas uses two methods on GraphicsContext to draw: paintBuffer drawImage (ImageBuffer version) I recently added a cross-platform Image* accessor (image()) to ImageBuffer. However this has only been implemented on the CG port so far. canvas is going to switch over to just grabbing an Image* from the ImageBuffer. This will eliminate the need for these extra methods on GraphicsContext. Every port will need to support the image() accessor on ImageBuffer for the new CSS Gradients feature to work also. Cairo, Qt and wx ports should go ahead and get this method implemented now. There will be more changes coming down the line as canvas is molded to be more cross-platform so that we can all share more code and reduce duplication of effort. Thanks, dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
