3.73 KB, patch
|Details | Diff | Splinter Review|
3.76 KB, patch
Jungshik Shin: review+
Jungshik Shin: superreview+
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 When clicking at any of the links to JPEG files with Chinese filename in the page, FireFox downloads the file instead of displays the file in the browser window. Reproducible: Always Steps to Reproduce: 1. Go to the URL. 2. Click at any of the JPG links with Chinese names. Actual Results: FireFox shows the "Opening..." dialog and asks to choose what to do with the file. Expected Results: Display the picture directly within FireFox window.
Odd. The site's headers appear to be invalid, since it should specify content-disposition: inline; filename=... and the filename should be encoded according to RFC 2231, but it seems odd that bad characters in the filename would force treating it as attachment, when the same headers without character issues doesn't. Same result in Seamonkey: --> Browser.
Assignee: bugs → file-handling
Component: File Handling → File Handling
Product: Firefox → Browser
QA Contact: bmo → ian
Version: unspecified → Trunk
Created attachment 164572 [details] [diff] [review] patch This will 'fix' this problem (I've already tested it). However, I'm not sure whether we have to do this because as noted in the previous comment, this is actually an 'evangelism' issue.
Assignee: file-handling → jshin
Status: UNCONFIRMED → ASSIGNED
Boris, what do you think of attachment 164572 [details] [diff] [review]? It's a bit hackish, but we may have to. An alternative is to tweak (a) nsIMIMEHeaderParam method(s).
OS: MacOS X → All
Hardware: Macintosh → All
That approach looks fine, but why the QIing? originCharset is an nsIURI property...
Created attachment 164850 [details] [diff] [review] patch update Thanks. I got rid of QIing.
Attachment #164572 - Attachment is obsolete: true
Comment on attachment 164850 [details] [diff] [review] patch update asking for r/sr
Comment on attachment 164850 [details] [diff] [review] patch update hmm... 95 NS_ASSERTION(!aTryLocaleCharset, "aTryLocaleCharset not yet supported !"); but sure. r=biesi
Attachment #164850 - Flags: review?(cbiesinger) → review+
Comment on attachment 164850 [details] [diff] [review] patch update sr=bzbarsky
Attachment #164850 - Flags: superreview?(bzbarsky) → superreview+
Created attachment 164984 [details] [diff] [review] patch for branches (1.7 and av1) This is identical to attachment 164850 [details] [diff] [review] as far as what this patch touches is concerned. The difference lies in the 'surrounding' where EqualsIgnorecase is used in place of EqualsLowerCaseLiteral (which was intrdouced in 1.8 cycle).
Comment on attachment 164984 [details] [diff] [review] patch for branches (1.7 and av1) carrying over r/sr from the trunk patch and asking for a to branches. I came across this bug from time to time. It's not critical, but kinda 'glitch' that may as well be removed in ff 1.0
marking as fixed as this was checked into the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
this caused bug 269806
Comment on attachment 164984 [details] [diff] [review] patch for branches (1.7 and av1) If this didn't make it in for Firefox 1.0 then I don't think we want it for 1.7.x since those two are supposed to be gecko equivalents. Please re-request if I'm wrong.
You need to log in before you can comment on or make changes to this bug.