1.04 KB, text/html
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; de-de) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10 Build Identifier: When i double click on an html file it seems that the page will open in the firefox browser because the firefox symbol appears but after that nothing happens. I can only open the html files on my mac if i start firefox, open a new window and that paste the html document with drag and drop into it. Please fix that bug cause i am a webdesigner and i always use firefox but this makes it hard to work. Reproducible: Always
Does the filenames or the paths to the files contains whitespace characters?
no they don't have whitespace...i am a webdesigner and i know how the files have to look like to work in browsers..and i could open the files with double-click before the update
Can you give an example file and also tell us the local path to the file? Is there any file that you can open or is this with *all* html files that you have on your machine?
thats the pronlem... it is with ALL html files i have on my machine... it worked before i downloaded the newest version so it cant be my files.
(In reply to comment #4) > thats the pronlem... it is with ALL html files i have on my machine... it > worked before i downloaded the newest version so it cant be my files. OK, but can you attach an example file anyway? It works fine for me, I can open all html files I have on my machine (10.5.8). Does .txt files work?
I have the same problem on Mac 10.5.8. I cannot open any files either .php or .html locally. In addition I cannot preview files from Dreamweaver in Firefox 3.6. I am also a web designer and I have scrapped 3.6 and gone back to 3.5 where everything works. I will now only upgrade when I know this bug has been fixed. There are a lot of people in the support forum complaining of the same issue.
Hi, I have the same problem on my iBook (G4 PPC; 10.4.11), and on my iMac (Intel, 10.6.2). I reverted to FF 3.5.8 for the time being.
Please see comment #5.
There is no point whatsoever attaching any files for you to open as there is nothing wrong with any of them. They all open perfectly well locally in every other browser including Firefox 3.5.8. I trashed 3.6 so I do not know if it would open .txt files, but as a web designer, I have no need to open .txt files. The only way to open local files in Firefox 3.6 is to physically paste the address in the address bar. Any other means, double clicking, right clicking - open with or preview from Dreamweaver do not work.
(In reply to comment #9) > There is no point whatsoever attaching any files for you to open as there is > nothing wrong with any of them. They all open perfectly well locally in every > other browser including Firefox 3.5.8. I'm not sure you understand. It could be that you're seeing bug 530064, which despite the title also probably could appear when a foldername has whitespace in it. And, just to be clear: by whitespace I mean "my file.html", "my folder". The bug probably also occur when your folder/file names have non-latin characters. The easiest thing to do for you is probably to test a build in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/ and see if you still see the problem.
And I don't think there is anything wrong with any of your files, the point with attaching a sample file and giving information about the path/folder names is to try to isolate the problem. And even if you don't care about text files, it's very useful to know if this occurs with any type of files or just some types.
Read these, just a few mentions of the same problem http://support.mozilla.com/en-US/forum/1/599882 http://support.mozilla.com/en-US/forum/1/566115? http://support.mozilla.com/en-US/forum/1/599999? http://support.mozilla.com/en-US/forum/1/599809? http://support.mozilla.com/en-US/forum/1/569127? http://support.mozilla.com/en-US/forum/1/568843?
I never use spaces of any sort in my naming conventions, for folders or filenames or non latin characters for that matter. I will try your test build solution.
Just downloaded Namoroka firefox-3.6.2pre.en-US.mac.dmg It does not open any .html or .php files through Dreamweaver or directly by right click and open in Namoroka. I checked to make sure there are no spaces either in folders or filenames. It did open the .txt file on my desktop.
(In reply to comment #14) > Just downloaded Namoroka firefox-3.6.2pre.en-US.mac.dmg > It does not open any .html or .php files through Dreamweaver or directly by > right click and open in Namoroka. > I checked to make sure there are no spaces either in folders or filenames. > It did open the .txt file on my desktop. Is this with an intel or ppc mac?
Actually, it's a bit confusing. I managed to reproduce the problem, but then when I tried again it worked.
Intel Mac and here are some other complaints https://support.mozilla.com/en-US/forum/1/594966#threadId600088 This should be treated as a major problem in view of the fact that many web developpers use Firefox.
I'm having trouble reproducing this in a consistent matter. When I right-clicked on a text file and tried to open it in Namoroka, the start page loaded instead. I then closed Namoroka and tried again, then the file opened in one window and the start page in another (the 2-window thing is bug 531552). The same thing happened when trying with a html file.
I did some research and found that FF 3.6 does not accept whitespace or special characters ANYWHERE in the local file path. I tried with (), umlauts, etc. In my local file paths I use characters permissible in MacOSX. Since I have a lot of local html files, I can't fix all that. So, for me this bug is very serious, and it should be fixed asap.
hans, that is bug 530064
to comment #9... IT HAS NOT!! I allready said that.. i cant upload any files because i only have the problems in the advertising agency i work, because at home i have the old version of firefox and not the new one. The documents on the mac in the agency are free for upload cause i dont have the permission to paste them anywhere!
are not free i meant
And happy news, that one is fixed for the next 3.6 update!
How can this be marked as a duplicate of bug 530654 which clearly states that files which contain a space do not open. I have no spaces in either file or folder names and still cannot open in 3.6 ?
P. S. or in Namoroka firefox-3.6.2pre.en-US.mac.dmg
Can you provide an example of a file that doesn't open? It doesn't have to be one of your work files. Just a file that you are unable to open.
This needs more investigating - it's quite clear that there is some kind of issue with opening "regular" files without spaces in filenames/paths. I can't reproduce it in a consistent matter, though - see comment #18.
Created attachment 429336 [details] simple test html file, no spaces in path, folder or filename I am using Namoroka pre to test this. It will open if dragged to Namoroka icon and will open from the folder - open with. It will in no way open from preview in Dreamweaver nor will any other file. I have not done this in Firefox 3.6 because as a web designer I need to test frequently from Dreamweaver and I have downgraded back to 3.5.8 to be able to work properly.
firstname.lastname@example.org, Just to clear out any misunderstandings here: The original report here says that no html file can be opened with Firefox. But for Namoroka (3.6.2pre) you mean that his only occurs when trying to preview files in Dreamweaver?
Following is list of bugs DUP'ed to bug 530064 which is already pointed in comment #10 by Stefan. > Bug 541377 Eudora function "Open in Browser" does not work in 3.6 (spaces in the temp file's name) > Bug 541498 Can't double-click to open html files with spaces in the filename > Bug 541765 html files with names containing spaces do not open from the Finder > Bug 541807 MHT files will not open in FF 3.6 via double-clicking or right-clicking > Bug 542921 double click on a local file no longer opens in firefox 3.6 > Bug 547948 Can't open local files. > Bug 549128 - FF 3.6 doesn't open any local files, FF 3.5 just works fine And, next two bugs are for Dreamweaver and they were immediately closed as Dup of already known bug 530064. > Bug 548419 3.6 and Dreamweaver CS4 > Bug 548650 The new version of Firefox (3.6) is not opening up the "preview in browser" window from Dreamweaver. To all problem reporter for Dreamweaver: What is difference of your problem from Bug 548419, Bug 548650 for Dreamweaver? To problem reporter to this bug even after bug 530064 is pointed: What is difference of your problem from bug 530064 and duped bugs to it? To Christin(bug opener): What is difference of your problem from bug 530064 and many many duped bugs to it? Do you check full path name of the file at file system level, in stead of "Display Name" by Finder only? Do you use "/" in file name and/or folder name by Finder("display name" by Finder)? Do you use HFS+ volume and other volumes of non-HFS+? (In reply to comment #2) > i am a webdesigner and i know how the files have to look like to work in browsers Does it mean that webdesigner never cares for file name / file path name(full path name) at file system level even after Mac OS X, as you did not do(no need to do, unable to do) during System 6/7 or Mac OS 8/9 era?
Response to Cpmment 31 "To all problem reporter for Dreamweaver: What is difference of your problem from Bug 548419, Bug 548650 for Dreamweaver? To problem reporter to this bug even after bug 530064 is pointed: What is difference of your problem from bug 530064 and duped bugs to it?" THE DIFFERENCE is that there are NO SPACES in file/folder/path names. And I just found this thread in the support forum https://support.mozilla.com/en-US/forum/1/561015#threadId561102 which indicates that although many people have this problem they have not filed a bug.
Reply to Comment 30 I cannot open any file in Namoroka pre through Dreamweaver CS3 preview. OK what I am going to do is download Firefox 3.6 again and test all files again.
(In reply to comment #32) > THE DIFFERENCE is that there are NO SPACES in file/folder/path names. No spaces at "Display Name" level of Finder? Or file system level "full path" of the file? For which file name are you talking? a) File name which Dreamweaver opens to edit/modify. b) File name which Dreamweaver passes to Fx for preview. Please note that file name of a) and file name of b) is usually never same, as many applications including Dreamweaver usually copies data to temporary file and passes the temporary file name(full path format at filesystem level, I think) to other application program(Fx in your case) for preview by the other application program. email@example.com, could you please explain clearly what is detailed difference of your problem with Dreamweaver from already dup'ed Bug 548419 & Bug 548650 which are phenomenon with Draeaweaver(which were immediately closed as Dup of already known bug 530064).
I just tested 3.6 Files or folders with spaces will not open, OK that is bug 530064 Files or folders with no spaces at file system level "full path" will open when double clicked, dragged to icon, or "open with" - Firefox Files or files in folders with no spaces at file system level "full path" will NOT open from Preview in Dreamweaver CS3 in this case file name b) In this last case Firefox window does not even open, nothing happens.
(In reply to comment #35) > Files or files in folders with no spaces at file system level "full path" will > NOT open from Preview in Dreamweaver CS3 in this case file name b) How did you know real full path of file name b) which was really passed to Fx by Dreamweaver? Set Fx 3.5 as default browser(or browser to whom Dreamweaver requests) and checked file:// URL at URL box of Fx 3.5?
Wada wrote "How did you know real full path of file name b) which was really passed to Fx by Dreamweaver?" File is on Desktop, in a folder called test, filename is index.html - I have no idea how Dreamweaver passes this to FX but I presume it would just follow this path? Wada wrote "Set Fx 3.5 as default browser(or browser to whom Dreamweaver requests) and checked file:// URL at URL box of Fx 3.5?" I have no problem with 3.5, the problem is with 3.6. Firefox is set as default browser.
(In reply to comment #37) > Wada wrote "Set Fx 3.5 as default browser(or browser to whom Dreamweaver > requests) and checked file:// URL at URL box of Fx 3.5?" > I have no problem with 3.5, the problem is with 3.6. Firefox is set as default > browser. Oother words: If you do next, you can check file path Dreamwever passes to Fx. - Set Fx 3.5 as default browser(or browser to whom Dreamweaver requests) - Request preview to Fx 3.5 from Dreamweaver - Check file:// URL at URL box of Fx 3.5
This is the path on 3.5, no spaces... file:///Macintosh/HD/Users/walterbusuttil/Desktop/test/index.html
This is the path on 3.5, no spaces... file:///Macintosh/HD/Users/walterbusuttil/Desktop/test/index.html
According to bug 530064 comment #20, full path of file(file system level) were like next. > "/Users/juela/Library/Application Support/Firefox/Profiles/default.gwc/bookmarks.html" doesn't work > "/Users/juela/Desktop/Photoshop Elements 6 - Bitte lesen.htm" also doesn't work. And, the reporter says; > Fehler: Warning: unrecognized command line flag -foreground Is /Macintosh/HD/Users/walterbusuttil/Desktop/... Finder level view? (Macintosh:HD:Users:walterbusuttil:Desktop:... like one) Or file system level view? (Does /Macintosh/HD exist at file system level?) Was error/warning message like above seen at Fx 3.6's Error Cosole when problem occurred? Bug 530064 is fixed by 1.9.3a1 and has .2-fixed status. Can you check with newest hightly build? (3.6.2pre or 3.7a1pre) > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/ > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
To Stefan(Assigned To: person of fixed bug 530064): Is Dreamweaver case different issue from bug 530064(space in path)?
(In reply to comment #42) > To Stefan(Assigned To: person of fixed bug 530064): > > Is Dreamweaver case different issue from bug 530064(space in path)? If there are no spaces in paths/filenames, yes. The fix in bug 530064 just made us escape the paths correctly. The question here is if this only happens when trying to open/preview files with Dreamweaver or if it also happens when opening files in general.
In reply to comment 41 I downloaded Minefield 3.7a2pre and ran the following trials, these are the results Test of Minefield. 1st try with Minefield open and running, from Finder right click - Open With, opened up the file. Path to file from address bar of Minefield file:///Users/lynne/Desktop/test/index.html 2nd try - Minefield installed on dock but not open, dragged file from folder to icon. File opened OK. File also opened from right click – Open With. Path to file in address bar file:///Users/lynne/Desktop/test/index.html 3rd try – Preview from Dreamweaver CS3 with same test file with no spaces – Preview does not work. Minefield does not open and there are no error messages.
If this is specific to Dreamweaver then we might have a problem similar to bug 403346. See this comment specifically: https://bugzilla.mozilla.org/show_bug.cgi?id=403346#c9 I'm pretty sure Firefox does not support 'WWW!OURL' any more.
(In reply to comment #45) > If this is specific to Dreamweaver then we might have a problem similar to bug > 403346. See this comment specifically: > https://bugzilla.mozilla.org/show_bug.cgi?id=403346#c9 > I'm pretty sure Firefox does not support 'WWW!OURL' any more. Good diagnosis. But if so, why next two bugs for Dreamweaver was immediately closed as DUP of bug 530064 just after bug open? > Bug 548419 3.6 and Dreamweaver CS4 > Bug 548650 The new version of Firefox (3.6) is not opening up the "preview in browser" window from Dreamweaver.
Why indeed, no-one was listening to us or dismissing the problem too quickly? That's why I kept on insisting. This is not bug 530064. It is a problem with DW preview in FF
(In reply to comment #47) firstname.lastname@example.org, thanks a lot for your testing and analysis and continuous reporting. Could you please open separate bug for Dreamweaver case even after fix of bug 530064, with referring your comment #39 and comment #44? If you'll open separate bug, I think Bug 548419 and Bug 548650 can be closed as DUP of your new bug, and this bug(comment #0) can be quickly closed as DUP of already known/repeatedly pointed bug 530064.
OK will do.
I will also inform support forums that this bug is being taken care of and make a lot of web designers happy...!
JFTR, lynne filed bug 549680.
Closing this bug(comment #0) as dup.