[FIX]1.0RC1 wants to download text/html;charset=iso-8859-1

VERIFIED FIXED in mozilla1.0

Status

Core Graveyard
File Handling
P1
major
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: Liam Quinn, Assigned: bz)

Tracking

({regression})

Trunk
mozilla1.0
regression

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

I have a private Bugzilla 2.14.1 that stopped working in 1.0RC1 because I
modified the Bugzilla scripts to return "Content-Type: text/html;
charset=ISO-8859-1" instead of "Content-Type: text/html". Sending the charset
parameter from my Bugzilla scripts worked fine in 0.9.9 and previous milestones.

With Mozilla 1.0RC1, attempting a query produces two download dialogs:
"Downloading bugzilla_bug_list.html" and "Downloading buglist.cgi". Each
download dialog says "You have chosen to download a file of type:
text/html;charset=iso-8859-1 from ..."

The problem seems to occur only with multipart/x-mixed-replace. I am able to
bring up individual bug reports, which unlike the query do not use
multipart/x-mixed-replace.

Editing the Bugzilla scripts to remove the charset parameter from the
Content-Type header allows me to view queries properly.

The following URL demonstrates the problem:

http://htmlhelp.com/test/mozilla/mixed-replace-with-charset.cgi

Mozilla 1.0RC1 wants to download this, which it shouldn't. Source for the CGI
script is here:

http://htmlhelp.com/test/mozilla/mixed-replace-with-charset.txt

If I omit the charset parameter from the Content-Type header, Mozilla 1.0RC1
displays the page:

http://htmlhelp.com/test/mozilla/mixed-replace-without-charset.cgi

Source for that script is here:

http://htmlhelp.com/test/mozilla/mixed-replace-without-charset.txt


Reproducible: Always
Steps to Reproduce:
1. View http://htmlhelp.com/test/mozilla/mixed-replace-with-charset.cgi


Actual Results:  Mozilla 1.0RC1 offered two download dialogs to download the
content of type "text/html;charset=iso-8859-1".

Expected Results:  Mozilla should have displayed the content as it does if the
charset parameter of the Content-Type header is omitted.

Comment 1

16 years ago
related: bug 61363 ?
Confirmed with a Linux CVS trunk build from yesterday.
Status: UNCONFIRMED → NEW
Ever confirmed: true
To darin.  Sounds like fallout from the nsIChannel freeze...  (though the code
_looks_ ok from here).
Assignee: new-network-bugs → darin
Created attachment 80315 [details] [diff] [review]
Patch to fix

I take that back.  It doesn't look OK after all... :)
bbaetz, darin, would you review?  The first hunk in the patch is the real fix
(changes BeginReading to EndReading so that we actually do the right thing). 
The other two hunks do a bit of cleanup in nsMultiMixedConv -- there's no need
for the decoder to store the type and charset separately, and this avoids
calling NS_ParseContentType() twice for every part of the multipart stream....

The first hunk should land on the 1.0 branch; the other two don't really have
to, imo.

And this affects all channels, not just multipart ones.  So thanks for catching
this, liam@htmlhelp.com (and thanks for the excellent testcase!).
Keywords: mozilla1.0, nsbeta1, regression
OS: Linux → All
Hardware: PC → All

Comment 6

16 years ago
*** Bug 133413 has been marked as a duplicate of this bug. ***
Comment on attachment 80315 [details] [diff] [review]
Patch to fix

oops.

r=bbaetz
Attachment #80315 - Flags: review+

Comment 8

16 years ago
Comment on attachment 80315 [details] [diff] [review]
Patch to fix

sr=darin

nice catch!  big time oops on my part ;-)
Attachment #80315 - Flags: superreview+
Checked in on trunk.  Mailed drivers for branch approval.  Taking bug so I can
keep track of it easily.  :)
Assignee: darin → bzbarsky
Priority: -- → P1
Summary: 1.0RC1 wants to download text/html;charset=iso-8859-1 → [FIX]1.0RC1 wants to download text/html;charset=iso-8859-1
Target Milestone: --- → mozilla1.0
Created attachment 80488 [details] [diff] [review]
Patch for branch

This is just the first chunk from the trunk patch (the minimum needed to fix
this bug).
Attachment #80315 - Attachment is obsolete: true

Comment 11

16 years ago
CONFIRMED:
I get described dialog on RC1 for Win 98.

-> File handling (w/ qa).

Boris, thanks for taking this.  
Component: Networking → File Handling
QA Contact: benc → sairuh

Comment 12

16 years ago
Comment on attachment 80488 [details] [diff] [review]
Patch for branch

you'll roll forward your r and sr?  a=scc for checkin to the mozilla 1.0 branch
Attachment #80488 - Flags: approval+

Comment 13

16 years ago
Comment on attachment 80488 [details] [diff] [review]
Patch for branch

sr=darin
Attachment #80488 - Flags: superreview+
Comment on attachment 80488 [details] [diff] [review]
Patch for branch

Rolling Bradley's review.
Attachment #80488 - Flags: review+
checked in on branch.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
*** Bug 141671 has been marked as a duplicate of this bug. ***
vrfy'd fixed using 2002.06.17.0x comm branch bits on linux rh7.2, win2k and mac
10.1.5, using the test url. no downloading occurred, just got a web page saying
"test part 2".
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.