[Webkit-unassigned] [Bug 20342] REGRESSION: fast/dom/cssTarget-crash.html fails

[bugzilla-daemon at webkit.org]

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





--- Comment #35 from Erik Arvidsson <arv at chromium.org>  2009-10-05 14:37:34 PDT ---
(In reply to comment #33)
> (In reply to comment #32)
> > I have a modified version of the layout test that terminates under both
> > circumstances.
> > 
> > However, it would be good if we could decide what behavior we want. Do we want
> > the form to get submitted to the server like IE and Opera or do we want to stay
> > on the current page without a submit like Firefox?
> > 
> > My vote is for the form to get submitted (current behavior).
> 
> As I understand it, the issue is: When you submit a form from JavaScript, is
> the decision of what URL to submit to at the time you call submit() or decided
> later on when the actual submission is done? Is that the right question?

There are two orthogonal issues here:

1. In Firefox, if there is no form data, the method is GET and the action is a
named element on the page (eg. #a) submitting the form does not leave the page.
It adds sets the hash to #a. If there is form data or there is no matching
named element on the page the form submit works as usual.

2. Changing the action after submit is called should not change the action of
the in flight submit.

> 
> You say that current behavior matches IE and Opera, but not Firefox. Does it
> also match Safari 4? Does HTML 5 have anything to say about this?

The current behavior of 1 matches IE, Opera and Safari 4. HTML5 says the
following:

Step 15 at http://dev.w3.org/html5/spec/Overview.html#concept-form-submit says
to do a Mutate action. Mutate action says to do a Navigate,
http://dev.w3.org/html5/spec/Overview.html#navigate. Point 4 of that says:

"Fragment identifiers: If the absolute URL of the new resource is the same as
the address of the active document of the browsing context being navigated,
ignoring any <fragment> components of those URLs, and the new resource is to be
fetched using HTTP GET or equivalent, and the absolute URL of the new resource
has a <fragment> component (even if it is empty), then navigate to that
fragment identifier and abort these steps."

"abort these steps" means that we should not fetch the resource and therefore
it seems like we are NOT doing the right thing in case 1.



The current behavior of 2 matches HTML5. The following happens when submit() is
called http://dev.w3.org/html5/spec/Overview.html#concept-form-submit and it
states in point 8 that it should use the action of the form when submitting,
not the action of the form when the js thread is done. 

> 
> > I can also add another layout test that ensures that behavior if that is the
> > behavior we want.
> 
> We definitely want that no matter what!


Conclusion: 

1. We need to fix the case where a GET form is submitted to the same URL +
fragment identifier.
2. The current layout test should pass and never time out
3. Add a layout test that tests that we submit to the current action when
submit() was called and later changes should not change that. This can be done
independently from the other fixes.
4. Add a new clearer layout test that tests that submitting an empty form to
the same url + fragment identifier does not replace the current page.

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