Closed
Bug 92158
Opened 23 years ago
Closed 23 years ago
Extension for recognized filetype not added if filename is changed in save as dialog
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
mozilla0.9.9
People
(Reporter: madhur, Assigned: law)
References
()
Details
I downloaded today's build via Netscape 4.77 Actual: I tried to download the installer build from build id: 200107123 and 20010724. I could not get the executable format of the application. I was getting the "type of file" as "File". expected: I should get the "type of file" as "Application".
Works for me. Like a problem with 4.x browser. Try downloading using IE or some other ftp app.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 2•23 years ago
|
||
I have been able to succesfully download today's build from Netscape 4.77 and IE. That is not the problem. The problem i am having is --- I am unable to download from Netscape BuildID : 20010724 and 20010723. Any reason?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The 20010724 that you mention that is not working is today's build. You are saying that it does work and that it also does not work. I'm confused. I'm assuming that you're talking about the branch since you've provided a URL. That url works for me. There is nothing wrong with downloading N6Setup.exe. I also just tried downloading all of yesterday's build using 4.76. It downloads fine. You have to undersdand that this is not a Mozilla or N6 problem since the bits are okay on the server. It's most likely either your network connection or your particular copy or 4.77.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 4•23 years ago
|
||
Madhur: please unconfuse Sean by trying to download some other random executable from some other server. It shouldn't matter *which* executable you are trying to download if downloading is broken. The installer is not involved in downloading the N6Setup.exe installer itself (obviously, since the workaround was to use a non-Mozilla browser) -- I think the choice of component was misleading. You say you were trying to *download* the branch, but was the build *doing* the download the branch or the trunk? If the branch this might be a stop ship bug, expecially if it's all executables from any server as I tentatively edited the summary to suggest. Changing component to Browser-General for lack of a better choice
Status: RESOLVED → REOPENED
Component: Installer → Browser-General
Resolution: WORKSFORME → ---
Summary: unable to download browser installer application from today's & yesterday's build → unable to download [executable] from today's & yesterday's build
Comment 5•23 years ago
|
||
Reassigning to Vishy, please find the right home for this potential stop ship bug (if it's as bad as my worst-case scenario -- it's unclear if the reporter is describing a trunk or branch build).
Assignee: ssu → vishy
Status: REOPENED → NEW
Reporter | ||
Comment 6•23 years ago
|
||
It is the branch build I am talking about. Sorry for not specifying earlier. As I have mentioned that downloading today's branch build from Netscape 4.77 was not a problem.
Reporter | ||
Comment 7•23 years ago
|
||
I have done some research about this and have come to a conclusion. when I am downloading anything using today's branch build - whether it be an application or Image or any other software - if I change the name of the file, I loose the format it has to be saved in. Say suppose - I do a "save image as" - and in the save dialog box I change the name of the file from (original name) to (new name) - instead of the image file being saved as ".gif", it is saved as a generic file. Whereas, when I save the image file with it's original name - i get the appropriate file format (ie.- ".gif") Now, similarly, is the case with the branch build application. ie. - if I save the installer applcation with a different name - it is saved as a generic file (looses it's extension), but if I save it with the original name - i am successful. I tried this on 3 different window2000 machines and I could reproduce the problem each time. I even did similar testing on Netscape4.77 - had *no* problem. I suppose this is specific to Netscape latest builds. Not sure - but i suppose the problem, here, is all together different. would you say Networking? Please look into this issue in more depth.
Comment 8•23 years ago
|
||
This does not sounds as serious as first described. Adding mscott and blake as they have more familiarity with this code and may know whats going wrong here.
Comment 9•23 years ago
|
||
since this seems like an internal netscape problem...
QA Contact: gemal → gbush
Comment 11•23 years ago
|
||
what you are describing is the way the windows file picker behaves. If you start typing a new name the windows file picker drops the previous extension & expects you to add an extension to your new file name. This isn't something we can really fix.
Comment 12•23 years ago
|
||
Thanks for the clarification Scott. In that case, I'm marking this as invalid.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 13•23 years ago
|
||
But I do not see this window file picker behaviour when i try to download/save a file using Netscape 4.77. This issue is specific to Netscape 6.1
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 14•23 years ago
|
||
madhur, is this still a problem for you with either recent 0.9.4-branch or trunk builds?
Assignee: vishy → law
Status: REOPENED → NEW
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
Reporter | ||
Comment 15•23 years ago
|
||
I'll check
Reporter | ||
Comment 16•23 years ago
|
||
Ok.... I still see a difference in behaviour when I am tring to download an executable using NS 6.2 vs. NS 4.77 using NS4.77 :- ============== 1. go to ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-10-09-06-trunk/ 2. click on N6Setup.exe 3. a 'save as' dialog box appears with the the following values --- File name = N6Setup File Extension = All Files(*.*) 4. change the file name to say -- N6Setup_1009_06trunk 5. click 'save' result:- the application is automatically saved with a .exe extension. The Type of File = "Application" ** this is a succesful download of an executable file - no problems seen here** Using NS 6.2 (i used today's branch build - 20011009-05-0.9.4):- ================================================================ 1. go to ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-10-09-09-trunk/ 2. click on N6Setup.exe 3. a 'save as' dialog box appears with the the following values --- File name = N6Setup File Extension = *.exe 4. change the file name to say -- N6Setup_1009_09trunk 5. click 'save' result:- The file is saved in a generic format. The Type of File = 'FILE'. (I followed the exact steps to download and save the executable as I did on NS4.77). The saved file here should actually be getting an extension '.exe' (but this is not happening) , as it did in my previous scenario. Moreover - the 'save as' dialog box came up with a default file extension as "*.exe" *** This is where I am seeing the problem ****** Now, if I go ahead and do the following for step 4 in NS6.2-- a) do not change the file name and leave it as original 'N6Setup' OR b) change the file name to "N6Setup_1009_09trunk.exe" (provide the extension here too) result:- the executable file is saved with a .exe extension and i get the Type of File = "APPLICATION" I should have provided these exact steps to reproduce the problem in my earlier comments. Please explain why is the 'save as' behaviour different for NS4.77 and NS6.2. Though there is a workaround (as described above) to save files in their proper format (NS6.2), I still feel that this is definitely going to confuse the user while saving certain files. In my case it was frustrating till I found a workaround.
Assignee | ||
Comment 17•23 years ago
|
||
Mass moving bugs that won't get fixed this milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 18•23 years ago
|
||
I see the same kind of problem with build 2002011803 on W2K. If I change the name of a download file in the save as-dialog, the extension (that is given in the file type below) is not attached to the file that is written to disk. I have checked a number of Windows applications, they all attach the extension to the name if a file type is recognized. Changing summary to something a little more generic...
Summary: unable to download [executable] from today's & yesterday's build → Extension for recognized filetype not added if filename is changed in save as dialog
Comment 19•23 years ago
|
||
Dup of "Filename 3-letter extension not applied when filename altered" *** This bug has been marked as a duplicate of 57113 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•