Last Comment Bug 111998 - sourceforge.net - Mozilla looses form data with SourceForge File Release system
: sourceforge.net - Mozilla looses form data with SourceForge File Release system
Status: RESOLVED WORKSFORME
aok
: regression, testcase, top100
Product: Tech Evangelism Graveyard
Classification: Graveyard
Component: English US (show other bugs)
: unspecified
: x86 All
: -- normal
: Jan
Assigned To: Doron Rosenberg (IBM)
: Zach Lipton [:zach]
Mentors:
http://sourceforge.net/project/admin/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-26 12:09 PST by Olivier Cahagne
Modified: 2015-04-19 23:39 PDT (History)
0 users
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
HTTP transaction (via sniffer) with Netscape 4.79 on Linux (2.38 KB, text/plain)
2001-11-26 12:10 PST, Olivier Cahagne
no flags Details
HTTP transaction (via sniffer) with Mozilla 2001112508 (2.31 KB, text/plain)
2001-11-26 12:12 PST, Olivier Cahagne
no flags Details
Testcase with input type=file incorrectly transmitted by Mozilla (612 bytes, text/html)
2001-11-27 03:35 PST, Olivier Cahagne
no flags Details

Description Olivier Cahagne 2001-11-26 12:09:32 PST
Build ID: 2001112508 on Win2k and Linux. Regression as it does work with
Netscape 6.2 (not Mozilla 0.9.6).

Steps to reproduce:
1. Load URL
http://sourceforge.net/project/admin/editreleases.php?package_id=11770&release_id=61920&group_id=12177
2. Enter 'Test' in the 'Release Notes' box,
3. Hit 'Submit/Refresh' button,
4. Data wasn't actually accepted as 'Release Notes' is still empty,
5. SF draws errors such as:

Warning: fopen("","r") - Success in
/usr/local/sourceforge.net/www/project/admin/editreleases.php on line 50

Warning: Supplied argument is not a valid File-Handle resource in
/usr/local/sourceforge.net/www/project/admin/editreleases.php on line 50

Warning: fopen("","r") - Success in
/usr/local/sourceforge.net/www/project/admin/editreleases.php on line 61

Warning: Supplied argument is not a valid File-Handle resource in
/usr/local/sourceforge.net/www/project/admin/editreleases.php on line 61

Expected results: working flawlessly, it works with IE6, Netscape 4.76, Netscape
6.2, not Mozilla 0.9.6 and later.

You have to be an admin to access above URL, if you have a SF account, let me
know, I'll give you admin rights for this bug. Otherwise, we can also setup a
dummy project to access this File Release form.
Comment 1 Olivier Cahagne 2001-11-26 12:10:39 PST
Created attachment 59195 [details]
HTTP transaction (via sniffer) with Netscape 4.79 on Linux
Comment 2 Olivier Cahagne 2001-11-26 12:12:14 PST
Created attachment 59196 [details]
HTTP transaction (via sniffer) with Mozilla 2001112508

With Mozilla, two items are missing from the transaction:

[...]
-----------------------------104195057818304962681319551376

Content-Disposition: form-data; name="uploaded_notes"; filename=""




-----------------------------104195057818304962681319551376

Content-Disposition: form-data; name="uploaded_changes"; filename=""


[...]
Comment 3 Olivier Cahagne 2001-11-26 12:16:05 PST
Both missing fields are these in HTML source code:

<input type="file" name="uploaded_changes" size="30">
 and
<input type="file" name="uploaded_notes" size="30">

So I guess a testcase would easily follow, perhaps it's even a dupe of an
already reported bug.

Comment 4 Olivier Cahagne 2001-11-27 03:35:46 PST
Created attachment 59307 [details]
Testcase with input type=file incorrectly transmitted by Mozilla

Click on the attachment, then enter something in the textarea ('test' for
example) then click Submit.
Either with a sniffer where you can see latest Mozilla build (2001112603) does
not transmit the 'input type=file', or with the results from the POST where you
can see the var is null.
With IE6 or Netscape 4.76, var is 'none' and a sniffer shows it's transmitted.
Comment 5 Olivier Cahagne 2001-11-27 03:38:01 PST
Changing Severity to blocker as it's one of the biggest Web sites, and this
behaviour has obviously changed since some weeks and might block many other Web
sites.
Comment 6 Olivier Cahagne 2001-11-27 03:42:33 PST
Marking dupe of bug 111963.

*** This bug has been marked as a duplicate of 111963 ***
Comment 7 jsp 2001-11-27 04:39:25 PST
Note that SourceForge ought not to rely on empty file controls being successful.
See http://www.w3.org/TR/html4/interact/forms.html#h-17.13.2, which says:
- "The current value of a file select is a list of one or more file names. Upon
submission of the form, the contents of each file are submitted with the rest of
the form data."
- "If a control doesn't have a current value when the form is submitted, user
agents are not required to treat it as a successful control."
Taken together, these statements allow browsers to treat a file select that
specifies no file names as unsuccessful, that is, to omit them from the
submitted data.

In other words, Mozilla's behavior is allowable, if inconvenient. I gather that
 it will be changed back, but other browsers that comply with HTML 4.01 may not.
If SourceForge is intended to be robust, it should accommodate the absence of
data for empty file inputs.
Comment 8 basic 2001-11-27 07:06:08 PST
should we make this an evang then?
Comment 9 Olivier Cahagne 2001-11-27 07:15:26 PST
I'd vote for both Evangelism and revert to original behaviour because it might
have broken many more sites, especially in an Intranet environment, where "input
type=file" are used a lot.
Comment 10 basic 2001-11-27 07:18:22 PST
well bug 111963 is going to fix the issue on mozilla's side and I'll reopen this
and send to tech evangelism then
Comment 11 Olivier Cahagne 2001-11-30 01:54:41 PST
now wfm using build 2001112903 on Win2k.
Severity back to Normal, still a Tech Evangelism bug though.
Comment 12 Olivier Cahagne 2001-12-21 03:36:23 PST
SourceForge now has a ticket for this issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=495432&group_id=1&atid=200001
Comment 13 Zach Lipton [:zach] 2002-01-03 11:18:08 PST
aok
Comment 14 Zach Lipton [:zach] 2002-01-03 11:19:10 PST
grr, sorry for all the spam
Comment 15 Olivier Cahagne 2002-12-12 21:06:46 PST
SF will not fix the issue, see the ticket.
Comment 16 Bob Clary [:bc:] 2002-12-13 05:38:12 PST
This appears to have been fixed in bug 111963 and it not a wontfix if we changed
our behavior -> reopen.
Comment 17 Bob Clary [:bc:] 2002-12-13 05:39:17 PST
wolruf, does this problem still occur for you?
Comment 18 Olivier Cahagne 2002-12-13 07:33:48 PST
Bob, it works for me.
Comment 19 Olivier Cahagne 2003-01-12 09:30:43 PST
Please reopen if you disagree.

Note You need to log in before you can comment on or make changes to this bug.