RESOLVED FIXED 4372
JavaScript document.write page form does not submit in Safari
https://bugs.webkit.org/show_bug.cgi?id=4372
Summary JavaScript document.write page form does not submit in Safari
Vicki Murley
Reported 2005-08-10 11:23:04 PDT
This bug is also in Radar as <rdar://4196379> Summary: Submitting an html form of a page that was written with a JavaScript document.write method does not work in Safari. We are concerned about this problem because we are using an encryption/decryption product that has the ability to decrypt a page and uses a document.write method to display the page. Steps to Reproduce: I have created a small page that demonstrates the problem. On load of the page it will use a document.write method to over write the current page with a page that has a form on it. Upon clicking on the submit button Safari does not submit the form; however Internet Explorer 6(WinXP) and Firefox (Mac) submits the form correctly. Example page writeform.html: <html> <head> <script> function writePage() { document.write("<html><head></head><body>" + "<form name='aform' action='servlet.html' method='post'>" + "<input type=submit></form>" + "</body></html>"); } </script> </head> <body onload="writePage()"> </body> </html> Expected Results: Safari would submit the form when clicking on the submit button. Actual Results: Safari does not submit the form and stays on current page. Regression: This problem occurred on the following platforms: Mac os X 10.3.9 Safari 1.3(v312) PowerBook G4 15-inch A1095. Mac os X 10.4.2 Safari 2.0(412.3) PowerBook G4 15-inch A1095. -------------------------------------------
Attachments
test case (279 bytes, text/html)
2005-08-10 11:23 PDT, Vicki Murley
no flags
patch, without tests or ChangeLog (531 bytes, patch)
2006-09-03 10:37 PDT, Alexey Proskuryakov
mjs: review-
proposed fix (3.60 KB, patch)
2006-09-23 20:34 PDT, Alexey Proskuryakov
darin: review+
Vicki Murley
Comment 1 2005-08-10 11:23:50 PDT
Created attachment 3313 [details] test case
Eric Seidel (no email)
Comment 2 2005-12-27 15:00:00 PST
Odd. When I hit the back button (after having hit submit), it tries to take me to /servlet.html
Alexey Proskuryakov
Comment 3 2006-09-03 10:37:50 PDT
Created attachment 10379 [details] patch, without tests or ChangeLog All layout tests pass, but it might be just because the reason for the removed check isn't covered... So, I'm asking about validity of such approach. A workaround is to call document.close() after writing.
Darin Adler
Comment 4 2006-09-03 12:11:19 PDT
Comment on attachment 10379 [details] patch, without tests or ChangeLog Oof! We *definitely* need tests for this one. I can't tell just from code inspection if this is OK or not. I'm not sure what to do about reviewing.
Alexey Proskuryakov
Comment 5 2006-09-14 08:38:35 PDT
The code in question appeared in WebCore in r1035: * src/kdelibs/khtml/khtml_part.cpp: Added. Not used yet, but maybe we'll use part of it some time soon. In the KDE repository, the condition has been tweaked many times, but the part I'm removing was introduced in r64718 six years ago: "applying stripped down version of my anti-tokenizer-crash-on-submit patch discussed on kfm-devel. It only prevents the crash. A complete solution for the form data has still to be found." http://websvn.kde.org/trunk/kdelibs/khtml/khtml_part.cpp?rev=64718&r1=64461&r2=64718 I couldn't find the mentioned kfm-devel discussion.
Maciej Stachowiak
Comment 6 2006-09-23 01:18:00 PDT
I think the approach is right but this needs a layout test.
Alexey Proskuryakov
Comment 7 2006-09-23 20:34:50 PDT
Created attachment 10730 [details] proposed fix
mitz
Comment 8 2006-09-27 14:42:30 PDT
(In reply to comment #5) > I couldn't find the mentioned kfm-devel discussion. http://lists.kde.org/?l=kfm-devel&m=96644872718833&w=2
Darin Adler
Comment 9 2006-09-28 09:09:22 PDT
Comment on attachment 10730 [details] proposed fix r=me
Alexey Proskuryakov
Comment 10 2006-10-01 01:41:09 PDT
Committed revision 16694. The fun begins!
Note You need to log in before you can comment on or make changes to this bug.