If you do a search using this link, you will notice it will bring up network locations. Of course these locations won't work for you (even with ie), because you aren't on the network. If you were on the network, it would only work in ie. I think that if you click on these links with mozilla, network neighborhood should be brought up with that location (or any other oses network browser). At least until mozilla can browse the network itself (if that is possible).

Can you explain your problem in more detail please. I get the following message when I goto the URL: Sorry, but http://rpi.phynd.net is for the private use of the RPI community only. Are you meaning paths that would be represented by windows as \\hostname\path\to\file and therefore should be accessed by browsers using the file:// protocol? This I think is definitely Windows specific (although don't know how Macs approach it), but using file: you can access NFS mounts under Linux as they're mounted in the filesystem. Anyway you should be able to access any network drives accessible from the file:// protocol in Windows if not then that's a bug, you shouldn't have to open an external file manager app to do this. See bug 60321, bug 70871

yes, shared directory folders that i guess are represented by file:// because thats what the links are on the site. Example: file://da%20pimp/music/dmx%20f.% 20sisqo%20-%20what%20these%20bitches%20want.mp3. It would be \\da pimp in windows. In Mozilla and Netscape 6 it just does nothing but changes the url to file://da% 20pimp///

That's bug 60231 for the behaviour you describe here, as for the launching explorer part of the bug that'll be handled by bug 68406 to allow URL schemes to be associated with different applications. e.g. file:/// with explorer.exe As this bug is about bringing up explorer I'm going to mark it as a dup of 68406. *** This bug has been marked as a duplicate of 68406 ***

Verified dup.

Is there currently a bug about actually having network browsing working within Mozilla? That would be preferred if it was ever added to actually loading Explorer's Network Browser.

I don't think this is a dup. If you look at that bug, the URI schemes were made to be blocked by that bug, not marked dupe. As this is a URI scheme, it should also depend on that bug (but not a dup as it is not the same bug). I have yet to figure out what bug 60231 has to do with anything. Marking this bug dupe would probably cause it to be marked fixed along with that other bug when it isn't finished.

60231 was a typo, I meant bug 60321 - mozilla can navigate network drives under windows exactly the same as local drives. This bug covers some of the problems that you're having. Sorting out this would solve your problem. OK, it does look like individual protocol schemes have got their own bugs filed against them but personally I think that is pointless as we could just fill up bugzilla with requests to support launching a helper app for each individual protocol scheme. The way I see it is that if bug 68406 is fixed support for all these schemes and any that you make up will come automatically. So to be honest I'd actually mark support for launching external apps by mailto:, telnet:, etc as either dupes of bug 68406 or invalid because of it. But as the bugs have currently been marked as a dependency I'm happy to keep it that way.

Definate dupe. *** This bug has been marked as a duplicate of 60321 ***

I will trust Ksosez's judgement on this one, although bug 60321 doesn't make any sense to me ;-)

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

REOPEN: implementing file URLs w/ a protocol handler solved this.

RESOLVED/FIXED: (no bug on implementation). http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/netwerk/protocol/file/src/nsFileProtocolHandler.cpp&rev=1.1&root=/cvsroot Mac OS X could also use the finder, per bug 203943.

Brian: will you verify your bug?

2003082704 (1.5b) Still doesn't seem to work. I tried: file://netdragon1/ \\netdragon1 file:////netdragon1/ file:///netdragon1/ file://\\netdragon1 None of these logical choices worked properly.

What OS are you using? Windows would be: file:///c:/

In Internet Explorer, it would be: \\netdragon1 (computer on my lan) file:///\\netdragon1 didn't work This was about networking browsing. Like samba shares, etc. It should open up the Explorer window for that computer. Windows XP SP1

Brian, that is really bug 62851, which I have reopened and updated. Can you verify this bug, which was to add the basic file: URL functionality?

This is about being able to browse samba shares (by bringing up a smb client like nautilus or explorer), and it's not simply windows-specific. file:///\\netserv and file://\\netserv works in IE, and smb://netserv, and smb:///netserv works for nautilus. We need a compatible way to browse network shares.

Dupe of bug 62851, but I don't like that bug's summary. *** This bug has been marked as a duplicate of 62851 ***

Brian, I think you've really asked for two things here, the smb aspect should be in another bug. Making file: URLs work more flexibily is easier to fix than adding a new protocol handler, espeically one that is not a clear specification for smb: URLs (that I can find), unlike, say nfs:, for example.

Ok, so then we should probably make smb:// URLs then just redirect to a file:// URL and have this bug depend on that one (or a helper application for smb://). That way we could fix the easy one first.

-> default owner