From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 BuildID: 2001091303 When a file has been selected to be downloaded, and mozilla is asking where to save the file, the name field is missing the first couple (usually 2) characters of the file name. This has happened to more than just one file on one server. Reproducible: Always Steps to Reproduce: 1.Goto www.fileplanet.com download a file. Notice the file name when saving is missing the first couple of characters. 2. 3. Actual Results: Always missing the first couple of characters from file name Expected Results: Used the exact file name from the server.
WFM 2001091403 on Win2k. New URL: http://lcix.tucows.com/mmedia/adnload/196134_76275.html (since no url was previously supplied, and I didn't have a "GameSpy ID" to login to fileplanet) Reporter: You may wish to try a fresh profile. You can create/manage profiles with "mozilla.exe -profilemanager".
In a similar bug, the problem wasn't missing characters, but that they didn't fully display. Selecting the text and dragging mouse to the left revealed that the leading characters were initially positioned wrong, out of view. Reporter: Can you try this and tell what happens? If there are still are no characters there: What happens if you save the file? Is the filename truncated as well?
If i try and drag the mouse, as you say, it doesn't scroll or anything. the characters are not there. I have noticed that if i make a new profile, it seems to correct the problem, however, if i switch to the modern profile, it causes this problem to reappear. very odd.
Assignee: mpt → ben
Component: User Interface Design → Skinability
QA Contact: zach → pmac
*** Bug 107683 has been marked as a duplicate of this bug. ***
*** Bug 106004 has been marked as a duplicate of this bug. ***
confirming based on dups
Status: UNCONFIRMED → NEW
Ever confirmed: true
18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
In some nightly builds this problem seemed to be fixed (I checked this at the end of October and the beginning of November, and it worked fine, but with the 0.96 milestone the error is still there.
still seeing in 2001122603 trunk
*** Bug 125791 has been marked as a duplicate of this bug. ***
*** Bug 153510 has been marked as a duplicate of this bug. ***
Here is a reproducible test case and an explanation. The URL http://xferla4.fileplanet.com/^1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 (or a slight variation of it) is included on the page mentioned above. During the request, it is translated into ...et.com/%5E176..., since "^" is defined as an "unwise" character that needs encoding by RFC 2396 (the URL specification ftp://ftp.isi.edu/in-notes/rfc2396.txt) in section 2.4.3. The server accepts the request for the file but includes a slightly truncated name in a Content-Disposition header (see below). I tested and confirmed this on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020622 built from CVS trunk (last updated yesterday, 2002-06-27 around 8pm) The person who reported it initially on #mozilla has: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020622 Build ID: 2002062213 A conversation recorded with WGET and two recorded with TELNET follow: Wget (entered on the command line _un_encoded): http://xferla4.fileplanet.com/%5E1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 => `/dev/null' Resolving xferla4.fileplanet.com... done. Connecting to xferla4.fileplanet.com[188.8.131.52]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Date: Fri, 28 Jun 2002 03:50:00 GMT 3 Server: GameSpy-XFS/1.0 4 Connection: close 5 Content-Type: application/octet-stream 6 Accept-Ranges: bytes 7 Content-Disposition: file; filename=art_tvrb.mp3 8 Last-Modified: Thu, 24 May 2001 00:27:36 GMT 9 Content-Length: 5057840 Telnet Encoded: telnet xferla4.fileplanet.com 80 Trying 184.108.40.206... [...] HEAD /%5E1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 28 Jun 2002 03:16:59 GMT Server: GameSpy-XFS/1.0 Connection: close Content-Type: application/octet-stream Accept-Ranges: bytes Content-Disposition: file; filename=art_tvrb.mp3 Last-Modified: Thu, 24 May 2001 00:27:36 GMT Content-Length: 5057840 Telnet Unencoded (illegal according to the RFC): HEAD /^1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 28 Jun 2002 03:18:14 GMT Server: GameSpy-XFS/1.0 Connection: close Content-Type: audio/mpeg Accept-Ranges: bytes Content-Disposition: file; filename=heart_tvrb.mp3 Last-Modified: Thu, 24 May 2001 00:27:36 GMT Content-Length: 5057840 Note that, while I can't make these decisions, I'm recommending: -> evang, US general
Oops, forgot to paste in some extra info (I cut/pasted it from a bug I almost filed) The page to find the link I mentioned is http://www.fileplanet.com/dl/dl.asp?/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3
Working with Tim but indedpendently, we came to a similar conclusion. I tend to agree that we're looking at a problem with the URLs.
Moving to networking. See comment 12 for why skinnability has nothing to do with it (removing modern keyword for same reason). My personal opinion is still tech evang, but we'll see where it goes.
Assignee: ben → new-network-bugs
Status: ASSIGNED → NEW
Component: Skinability → Networking
QA Contact: pmac → benc
-> file handling: can someone please add an example to the URL field + state the expected and observed filenames?
Component: Networking → File Handling
I'd provide a URL, but they seem to expire rather quickly, and I only managed to do my testing when someone in #mozilla had an account and provided me with a (then-working) direct link. From my description in comment 12, the expected filename is heart_tvrb.mp3 and the actual is art_tvrb.mp3. The cause of this difference is that the *server* is sending the wrong filename in the Content-Disposition header when the "^" at the beginning of the URL is encoded (and only when it is encoded). Presumably, it works in IE because they ignore the filename (if not the whole header) given by Content-Disposition. I believe the proper resolution would be to contact the server vendor and tell them to read RFC 2396 (section 2.4.3) to get encoding/decoding correct. An alternate resolution would be to ignore filenames that are specified in Content-Disposition in certain cases (or altogether), but I wouldn't personally stand behind that recommendation.
(finally changing ownership. sorry for spam of my jet-lagged failures from before.)
Assignee: new-network-bugs → law
QA Contact: benc → sairuh
*** This bug has been marked as a duplicate of 136831 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.