While using flickr website, I tried to add a comment to a photo and it can't be done. After pressing the POST COMMENT button nothing happens. I tried using Safari 3.1 and Firefox on the same computer and it works fine.
I am having this same problem, I just downloaded the latest release of WK and the problem still exists.
I'm seeing this behaviour on WebKit "3.1.2 (5525.20.1)". Should this bug have the keyword "YahooBug"?
<rdar://problem/6092270>
Just to be clear, did you mean this didn't work with the released 3.1.2, or with a WebKit build running against 3.1.2? I just tried it on a stock 10.5.4/3.1.2 machine and had couldn't reproduce.
Webkit v35289 downloaded on July 23rd doesn't work. Official Safari v3.1.2 (5525.20.1) does work. I'm on a Macbook CoreDuo 2Ghz with MAC OS X 10.5.4 with every Apple software up to date.
works in r35138 broken in r35153
Regressed with http://trac.webkit.org/changeset/35151
This issues occurs when your original url as a trailing slash. Flickr adds a #preview to the url before doing another load to add the comment. The new code added in r 35151 prevents reloading in that case where #preview is added. I don't know how we can tell the difference between the case where the site adds a hash and intends to do more processing on a reload, and when a user adds a hash to jump somewhere in the page.
Ugh. Does this work on Firefox 2.0/3.0? Perhaps we're missing a "userInitiatedLoad" flag to know when the change was done by JavaScript versus the user.
I'm going to look into this.
(In reply to comment #9) > Does this work on Firefox 2.0/3.0? Seeing the same problem in Adium's trac system and others - they all add #preview etc. This works from current Safari 3.1.2, and Firefox 2 and 3.0.1 but not from the latest (27 July) WebKit nightly. I first noticed this problem in r35249 (built on 20 July 2008), fwiw.
*** Bug 20195 has been marked as a duplicate of this bug. ***
Unfortunately r35377 just refactored many of the methods. Not sure if this is going to help or hurt. http://trac.webkit.org/changeset/35377
I have a fix! The problem is that FrameLoader::m_formAboutToBeSubmitted is never set on a form that doesn't have any "text fields", which causes a FormState object not be created, which causes isFormSubmission not to be set to true, which means that shouldScrollToAnchor() returns true instead of false. Next step is to run layout tests and to write a new layout test.
(In reply to comment #11) > Seeing the same problem in Adium's trac system and others - they all add > #preview etc. This works from current Safari 3.1.2, and Firefox 2 and 3.0.1 > but not from the latest (27 July) WebKit nightly. Dan, what are the steps to reproduce this issue?
(In reply to comment #15) > (In reply to comment #11) > > Seeing the same problem in Adium's trac system and others - they all add > > #preview etc. This works from current Safari 3.1.2, and Firefox 2 and 3.0.1 > > but not from the latest (27 July) WebKit nightly. > > Dan, what are the steps to reproduce this issue? I tried creating a preview of a new ticket on macosforge.net, but the preview button still works there (even though it adds "#preview" to the URL). See Comment #14.
(In reply to comment #15) > (In reply to comment #11) > > Seeing the same problem in Adium's trac system and others - they all add > > #preview etc. This works from current Safari 3.1.2, and Firefox 2 and 3.0.1 > > but not from the latest (27 July) WebKit nightly. > > Dan, what are the steps to reproduce this issue? Now using WebKit r35531, still on OS X 10.4.11. Pick a ticket, any ticket, on AdiumX's trac. eg: http://trac.adiumx.com/ticket/10582 Scroll to the end and login. Put text into the comment field. Hit "Preview" The url is rewritten to have #preview on the end, but other than that, nothing happens.
(In reply to comment #17) > Pick a ticket, any ticket, on AdiumX's trac. > eg: http://trac.adiumx.com/ticket/10582 > Scroll to the end and login. > Put text into the comment field. > Hit "Preview" > The url is rewritten to have #preview on the end, but other than that, nothing > happens. Okay, this is the same issue. Thanks!
Created attachment 22662 [details] Patch v1 Patch with changelog and manual test. An automated test couldn't be made since it would always succeed (used a different code path than manually clicking on the Submit button).
Comment on attachment 22662 [details] Patch v1 Coming soon: automated layout test.
Created attachment 22669 [details] Patch v2 Now with automated regression test. My mistake before when creating an automated test was that I tried to submit the form before the page was finished loading, preventing the bug from reproducing.
Comment on attachment 22669 [details] Patch v2 Looks good to me!
$ git svn dcommit Committing to http://svn.webkit.org/repository/webkit/trunk ... M LayoutTests/ChangeLog A LayoutTests/fast/forms/submit-to-url-fragment-expected.txt A LayoutTests/fast/forms/submit-to-url-fragment.html M WebCore/ChangeLog M WebCore/html/HTMLFormElement.cpp M WebCore/loader/FrameLoader.cpp M WebCore/loader/FrameLoader.h Committed r35611
(In reply to comment #7) > Regressed with http://trac.webkit.org/changeset/35151 See Bug 13067.