387991 - Sending form data broken

Status: RESOLVED DUPLICATE of bug 384270

(Core :: DOM: Core & HTML, defect)

Description

[Jochen Wiedmann]

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.

Comment 1

[monkeypox37]

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.

Comment 2

[David Nesting]

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. 

Comment 3

[Morris-moz]

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