Closed Bug 387991 Opened 14 years ago Closed 14 years ago
Sending form data broken
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6 I am a frequent user of the Jira issue tracking system. In particular, I am using Jira at the sites http://issues.apache.org/jira. When using Gran Paradiso (3.0a6, as of this writing), Jira is almost unusable: In various situations, after posting form data, I receive very strange error messages from Jira, that indicate a corrupt input stream. See, for example, my posting on http://www.nabble.com/Upload-request-(cannot-submit-via-Jira)-t3948653s177.html I initially considered this to be a bug in Jira and filed bug reports there. However, in the meantime I found out, that I have no problems using the same Jira installations with IE 7 or Firefox 2. Consequently, I do now believe that the problem is Gran Paradiso's fault. Reproducible: Always Steps to Reproduce: 1. Visit the URL for creating an issue in the Apache "Test project": https://issues.apache.org/jira/secure/project/ViewProject.jspa?pid=10650 2. Click on "Create new Issue" and enter the following data: Project = "Test Project" Type = "Bug" 3. Click on "Next" and enter the following data: Summary = "Validate Gran Paradiso's form data sender" Description = "See http://www.nabble.com/Upload-request-(cannot-submit-via-Jira)-t3948653s177.html" 3. Click on "Create". Actual Results: An error message appears: Create Issue Step 2 of 2: Enter the details of the issue... Errors * Error instantiating webwork.multipart.parser.class: com.atlassian.jira.web.JiraMultipartRequestWrapper(original message: null) You have not selected a valid project to create an issue in. Expected Results: Jira should create the new issue.
Component: Form Manager → HTML: Form Submission
Product: Firefox → Core
QA Contact: form.manager → form-submission
Version: unspecified → Trunk
OK, I created an account at that place to test this since I thought it was the same thing as something similar that came up for a user on the Mozillazine forums. Confirmed with the latest nightly. The other incident was posting to the Ars Technica forums, the regression range for that was 5/13 -> 5/14 (#116346, we're lookin' at you). I didn't do the amount of testing I did with the Ars thing since I didn't keep all the extra copies of FF around but did verify that the 5/13 nightly does work and the bug entry that Jochen outlined above was filed on that Test Project with that build. In bug #116346 there's a boolean preference set up to not do the new behavior (IIRC it defaults to not do it) but it only applies to the first check-in, the second check-in went in without that if...else argument. It could be something else too, but I don't have a FF build machine to try it out.
If bug 116346 caused this problem, can we identify whether Firefox (post-116346) is doing the wrong thing, or if Jira simply isn't parsing multipart/form-data requests correctly? Some cursory scanning of Jira bugs suggests this has been identified on the Jira side as a parsing issue. If we think this is accurate, we could close this bug.
I am that Mozillazine user mentioned in comment #1. This is the topic concerned: http://forums.mozillazine.org/viewtopic.php?t=567643 Apart from the Ars Technica forums, the other problematic form is at: http://apply.aquent.com
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 384270
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.