[Webkit-unassigned] [Bug 31097] <FORM> sends the form-data to the URL specified in "action" only once.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 15 19:55:38 PST 2010


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


Johnny Ding <jnd at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ap at webkit.org,
                   |                            |eric at webkit.org,
                   |                            |jnd at chromium.org




--- Comment #8 from Johnny Ding <jnd at chromium.org>  2010-01-15 19:55:37 PST ---
After digging in WebCore, I found this problem was because the algorithm of
preventing a single form from submitting more than once. (The logic is in
FrameLoader::submitForm.)

I am not familiar with the context of the multiple form submission issue. So I
had a few questions for this algorithm. Please correct me if those questions
looks stupid:)

1. I checked the situation of submitting a single form more than once on both
IE and Firefox. They do allow this. Why WebKit disallow this behavior if people
explicitly want to do this. Please check comments #5 on http://crbug.com/26662.

2. According to the comments of current algorithm of suppressing multiple form
submissions (line 471, FrameLoader.cc), when starting handle a new mouse or key
down event, m_submittedFormURL will be reset to empty to allow another
submission. Which means this algorithm does allow users to explicitly submit
more than once on a single form. Am I right?

3. Although above comments said when handing a new mouse event or key down
event, m_submittedFormURL will be reset to empty to allow another submission.
But the truth is only key event was taken care.
When testing on http://club.china.com, after the first submission, if you click
the search button again, nothing happened. But when you press keyboard on
anywhere of webpage (didn't need to focus on the query input control to change
the query), then click the search button again, a new tab will be opened for
same query (if didn't change the query).  This behavior really makes users
confused.

4. In current algorithm, it checked the frame target. If the current frame is
descendant of the target frame, m_submittedFormURL would be used to check
whether this submission is as same as previous one.(line 479-482,
FrameLoader.cc) But the thing also makes me confused is when frame target is
"_blank", the above logic also was hit. I think the "_blank" frame is obviously
not ancestor of any frame. After checking the code, I think it was because we
passed current frame to target frame when not finding out the target frame by
name of target frame since findFrameForNavigation will return NULL when input
is "_blank". I personally this it should be a error. When I checked the
original patch (https://bugs.webkit.org/attachment.cgi?id=29178&action=diff),
the original logic of checking target frame looked right.

If you agree with my analysis. I gonna provide a patch to fix this issue.

A immature idea to ignore too frequent submission and allow normal multiple
submissions for a simple form is to add a timer to reset the
m_submittedFormURL. For example, after submitting a form, a 3 seconds timer
will be created to reset the m_submittedFormURL, so in the 3 seconds, users can
not re-submit the form until if timer is expired. Just for your reference

So far I don't have other ideas to fix the multiple form submission issue in
another better way, What I want to do to fix above problems in current way are.

1) correct the logic of checking frame target, the pseudo code looks like
    bool foundTarget = true; 
    Frame* targetFrame = findFrameForNavigation(targetOrBaseTarget);
    if (!targetFrame) {
        foundTarget = false;
        targetFrame = m_frame;
        frameRequest.setFrameName(targetOrBaseTarget);
    }
    ...
    if (foundTarget && m_frame->tree()->isDescendantOf(targetFrame)) {
    ...

2) add the logic of reset multiple form submission protection when handling a
mouse press event
EventHandler::handleMousePressEvent(...) {
   ...
   m_frame->loader()->resetMultipleFormSubmissionProtection();
}

3) add a layout test to test multiple submission.

I am looking forward to your feedback.
Thanks!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list