when saving a file some characters from the name are missing



18 years ago
3 years ago


(Reporter: skibo, Assigned: law)


Windows 2000

Firefox Tracking Flags

(Not tracked)




18 years ago
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.

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:
(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".

Comment 2

18 years ago
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?

Comment 3

18 years ago
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.

Comment 4

18 years ago
Assignee: mpt → ben
Component: User Interface Design → Skinability
Keywords: modern
QA Contact: zach → pmac

Comment 5

18 years ago
*** Bug 107683 has been marked as a duplicate of this bug. ***

Comment 6

18 years ago
*** Bug 106004 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
confirming based on dups
Ever confirmed: true
Target Milestone: --- → Future

Comment 8

18 years ago
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.

Comment 9

17 years ago
still seeing in 2001122603 trunk

Comment 10

17 years ago
*** Bug 125791 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
*** Bug 153510 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
Here is a reproducible test case and an explanation.

(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):
           => `/dev/null'
Resolving xferla4.fileplanet.com... done.
Connecting to xferla4.fileplanet.com[]: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
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

Comment 13

17 years ago
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

Comment 14

17 years ago
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.

Comment 15

17 years ago
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
Component: Skinability → Networking
Keywords: modern
QA Contact: pmac → benc

Comment 16

17 years ago
-> file handling:

can someone please add an example to the URL field + state the expected and
observed filenames?

Comment 17

17 years ago
Component: Networking → File Handling

Comment 18

17 years ago
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.

Comment 19

17 years ago
(finally changing ownership. sorry for spam of my jet-lagged failures from before.)
Assignee: new-network-bugs → law
QA Contact: benc → sairuh
QA Contact: sairuh → petersen

*** This bug has been marked as a duplicate of 136831 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.