Closed Bug 39036 Opened 21 years ago Closed 19 years ago

Linux filepicker doesn't show hidden directories or files (dotfiles)

Categories

(Core :: XUL, enhancement, P2)

x86
Linux
enhancement

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: hacksaw, Assigned: bryner)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: relnote-user)

Attachments

(1 file)

Go to mail/news
Select Import... from the file menu
Try and find .netscape or .exmh or .any_damn_thing
reassigning to chuang.
Assignee: putterman → chuang
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: lchiang → esther
cc'ing pavlov.  Is this controlled by the code calling the file picker or is
this a file picker bug? Marking M18.
Target Milestone: --- → M18
pass to tonyr.
Assignee: chuang → tonyr
Keywords: correctness, nsbeta3
I think my import tools are only accessed from Tools->Import, not from the File 
menu.  I'm not sure what File->Import... calls.
Assignee: tonyr → chuang
File->Import... calls the same function as Tools->Import.
cc'ing tonyr.  Please take this back if it's yours.
Keywords: mail4
+ per mail triage
Whiteboard: [nsbeta3+]
reassign back to Tony.  See candice's comments.
Assignee: chuang → tonyr
this should be marked as a dup of the convert nsIFileSpecWithUI to nsIFilePicker
for mailnews bug that sspitzer has.  nsIFileSpecWithUI is going away, and this
bug is invalid with the new file picker.
*** Bug 36483 has been marked as a duplicate of this bug. ***
Anyone want to review the fix and I'll check it in?  I just switched to 
nsIFilePicker and converted the returned file to an nsIFileSpec for the 
underlying import code which still requires nsIFileSpec's.

Index: importDialog.js
===================================================================
RCS file: /cvsroot/mozilla/mailnews/import/resources/content/importDialog.js,v
retrieving revision 1.11
diff -r1.11 importDialog.js
423a424,435
> function CreateNewFileSpecFromPath( inPath)
> {
> 	var file = 
Components.classes["component://netscape/filespec"].createInstance();
> 	if (file != null) {
> 		file = file.QueryInterface( Components.interfaces.nsIFileSpec);
> 		if (file != null) {
> 			file.nativePath = inPath;
> 		}
> 	}
> 
> 	return( file);
> }
451c463
< 			var filePicker = 
Components.classes["component://netscape/filespecwithui"].createInstance();
---
> 			var filePicker = 
Components.classes["component://mozilla/filepicker"].createInstance();
453c465
< 				filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFileSpecWithUI);
---
> 				filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFilePicker);
455c467
< 					// filePicker.create( window.top, 
GetBundleString( 'ImportSelectSettings'), filePicker.modeLoad);
---
> 					var file = null;
457,459c469,485
< 						filePicker.chooseInputFile( 
GetBundleString( 'ImportSelectSettings'), filePicker.eAllFiles, null, null);
< 						setIntf.SetLocation( 
filePicker.QueryInterface( Components.interfaces.nsIFileSpec));
< 					} catch( ex) {
---
> 						filePicker.init( top.window, 
GetBundleString( 'ImportSelectSettings'), 
Components.interfaces.nsIFilePicker.modeOpen);
> 						filePicker.appendFilters( 
Components.interfaces.nsIFilePicker.filterAll);
> 						filePicker.show();
> 						if (filePicker.file && 
(filePicker.file.path.length > 0))
> 							file = 
CreateNewFileSpecFromPath( filePicker.file.path);
> 						else
> 							file = null;
> 					}
> 					catch(ex) {
> 						file = null;
> 						error.value = null;
> 						return( false);
> 					}					
> 					if (file != null) {
> 						setIntf.SetLocation( file);
> 					} 
> 					else {
524c550
< 			var filePicker = 
Components.classes["component://netscape/filespecwithui"].createInstance();
---
> 			var filePicker = 
Components.classes["component://mozilla/filepicker"].createInstance();
526c552
< 				filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFileSpecWithUI);
---
> 				filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFilePicker);
529,530c555,561
< 						filePicker.chooseDirectory( 
GetBundleString( 'ImportSelectMailDir'));
< 						mailInterface.SetData( 
"mailLocation", CreateNewFileSpec( filePicker.QueryInterface( 
Components.interfaces.nsIFileSpec)));
---
> 						filePicker.init( top.window, 
GetBundleString( 'ImportSelectMailDir'), 
Components.interfaces.nsIFilePicker.modeGetFolder);
> 						filePicker.appendFilters( 
Components.interfaces.nsIFilePicker.filterAll);
> 						filePicker.show();
> 						if (filePicker.file && 
(filePicker.file.path.length > 0))
> 							mailInterface.SetData( 
"mailLocation", CreateNewFileSpecFromPath( filePicker.file.path));
> 						else
> 							return( false);
615c646
< 		var filePicker = 
Components.classes["component://netscape/filespecwithui"].createInstance();
---
> 		var filePicker = 
Components.classes["component://mozilla/filepicker"].createInstance();
617c648
< 			filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFileSpecWithUI);
---
> 			filePicker = filePicker.QueryInterface( 
Components.interfaces.nsIFilePicker);
635,636c666,672
< 				filePicker.chooseDirectory( GetBundleString( 
'ImportSelectAddrDir'));
< 				file = filePicker.QueryInterface( 
Components.interfaces.nsIFileSpec);
---
> 				filePicker.init( top.window, GetBundleString( 
'ImportSelectAddrDir'), Components.interfaces.nsIFilePicker.modeGetFolder);
> 				filePicker.appendFilters( 
Components.interfaces.nsIFilePicker.filterAll);
> 				filePicker.show();
> 				if (filePicker.file && 
(filePicker.file.path.length > 0))
> 					file = filePicker.file.path;
> 				else
> 					file = null;
644,645c680,686
< 				filePicker.chooseInputFile( GetBundleString( 
'ImportSelectAddrFile'), filePicker.eAllFiles, null, null);
< 				file = filePicker.QueryInterface( 
Components.interfaces.nsIFileSpec);
---
> 				filePicker.init( top.window, GetBundleString( 
'ImportSelectAddrFile'), Components.interfaces.nsIFilePicker.modeOpen);
> 				filePicker.appendFilters( 
Components.interfaces.nsIFilePicker.filterAll);
> 				filePicker.show();
> 				if (filePicker.file && 
(filePicker.file.path.length > 0))
> 					file = filePicker.file.path;
> 				else
> 					file = null;
655c696
< 		file = CreateNewFileSpec( file);
---
> 		file = CreateNewFileSpecFromPath( file);

*****CVS exited normally with code 1*****

Status: NEW → ASSIGNED
cc: putterman
Keywords: mailtrack
Blocks: 34051
Converted the dialog to use nsIFilePicker rather than nsIFileSpecWithUI.  The 
underlying import code still uses nsIFileSpec though - it would be a major 
effort to switch to the new file classes.  (After all, import does a lot of work 
navigating directories and reading/writing/creating/deleting files.)
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Um, so.... this may break again when I land the rdf filepicker branch.  The
filesystem datasource by default ignores hidden files entirely.

I've talked some with rjc about how we can solve this.  I am willing to fix it
but I'd request this be re-triaged to see if we really need it for beta3.
Actually, I will go ahead and reopen this and assign it to myself until we get
this resolved, since I am landing the branch now.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
-> me
Assignee: tonyr → bryner
Status: REOPENED → NEW
Status: NEW → ASSIGNED
clearing nsbeta3+ for triage by new owners.
Is opening the old AB in a .directory the typical case for import, or does that
normally get converted on profile migration?  Also, isn't Import usually done on
an AB that is explicitly Exported, or Saved?  I'm trying to determine how
critical a need we have for displaying .directories. Also, is the workaround of
typing the explicit path in sufficient?
Whiteboard: [nsbeta3+]
nsbeta3-/future, 'native' file pickers don't have any easy way to show these either.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
Keywords: mail4, mailtrack
better summary
Component: Address Book → XP Toolkit/Widgets
Product: MailNews → Browser
Summary: Import addressbook open dialog doesn't show hidden directories or files → Linux filepicker doesn't show hidden directories or files
i'll take this (unless esther minds ;).
QA Contact: esther → sairuh
*** Bug 56991 has been marked as a duplicate of this bug. ***
mozilla 0.9... we should introduce some sort of "Show hidden files" checkbox in
the filepicker dialog.
Target Milestone: Future → mozilla0.9
If other apps using the native filepicker are also unable to show hidden files, 
surely this doesn't merit a relnote? Please nominate if you disagree...

Gerv
bryner: I suggest we introduce some XP notion of what the OS settings are on
showing/hiding "hidden" files, then use that information in the filesystem
datasource.

Of course, we can always to the checkbox (or whatever) thing (too) :-)
relnote to endusers: summary sez it all: you'll not be able to view your hidden
files or dirs [eg, dot files, dot directories] using either the linux [xul]
filepicker --or by viewing a directory listing [file://] in the browser's
content window.

this problem is specific to unix/linux, and doesn't occur with the native
filepickers or dir views on Mac or Win32.
Keywords: pp
Summary: Linux filepicker doesn't show hidden directories or files → Linux filepicker or file:// view doesn't show hidden directories or files
Whiteboard: [nsbeta3-] → relnote-user
*** Bug 62662 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9 → mozilla1.0
*** Bug 60293 has been marked as a duplicate of this bug. ***
with bryner's rewrite of the file picker [see bug 75838], you can easily turn on
display of dot files/dirs by changing 'false' to 'true' in the following line of
xpfe/components/filepicker/res/content/nsFileView.js

  this.mShowHiddenFiles = false;

bryner, could this be turned on by default? i find it quite useful to view and
trowel through dot files and dirs... you had suggested adding a checkbox in the
file picker dialog as an alternative --mpt, would it be better to just have this
turned on, or have the checkbox there? [i'd prefer a less cluttered dialog
without the checkbox, but don't have strong feelings either way.]
Keywords: nsbeta1
I have like 226 .* files. It should be a check box.

Even better would be a regexp matcher that works better than the very old
sunview one.

Its default regexp would be [^\.].* , that is, anything that doesn't start with
a '.'.

Perhaps the list of patterns could be replaced by this, or perhaps it should pop
up if the user selects the entry "other" from that list.

A side comment: perhaps the button at the top of the dialog should have an
left-up arrow instead of ".."?

  A
  |___ instead of ..

This is starting to smell like feature creep to me.  I doubt we have much real
user need for this in the product; nobody has offered any typical end-user
scenarios where this feature would be needed.  However, if it is as trivial as
it sounds, I would caution that it be added in as non-intrusive a manner as
possible.  I concur with Jag's earlier suggestion of basing it on a system pref,
where one exists. I doubt it is worth complicating the UI with a pref, let alone
a button in the file picker. I am very much against having it enabled by
default, and God forbid we should have users editing regular expressions! 
However, this capability obviously appeals to mozilla developers (and sure, I'd
use it once in a while too), so perhaps any such UI could be added as an
overlay?
i certainly wouldn't mind having a backend pref for this, nor would i mind [esp
after reading hacksaw's comment] having said pref off by default. how doable
would that be?
Having it be a pref (as in "changeable with the preferences dialog") is a lose.

It almost always going to be a temporary thing, so having to change it in the
prefs dialog is just annoying, because then you'll want to change it back.

That's why a button in the dialog is the best solution.

However, RE's, or at least file globs would be preferable.

Think about using composer. I'd like to edit all the file from my old MS server,
all with a ".htm" suffix. Just the .htm's thanks, the other are done.

I'd like to look at all my files called my*.html.

I'd like to look at the files ending in .doc (which I use to indicate complete
documents, not damned MS word files... but I digress)

I'd like to see all the file ending in html and txt, but not the 400 jpegs.

And, importantly, I'd like to be able to find all the cute little iconized
jpeg's left by xv and ee, some would make great icons. 

If I had my druthers, I'd want a checkbox on the page for file:// listing as well.

Another side comment: The history thing at the top? I think that it'd be better
as a cascade listing of the path, ala the gimp or Mac OS finder window titles.
> --mpt, would it be better to just have this turned on, or have the checkbox
> there?

In the filepicker, I think `Show Hidden Files' should be a checkbox item at the
bottom of the shortcut menubutton (the same menubutton which provides shortcuts
to your home directory, and to mounted devices determined through mntent and
friends). It would default to off.

For a file:// listing, I think hidden files should always be shown, with no
exceptions. Showing a file listing in your Web browser is an advanced task
anyway, so showing hidden files is quite acceptable.

Peter, I think the necessity for this feature is demonstrated quite well by the
original bug report.
MPT: if that were the case, I would have expected answers to the questions I
asked in here last September.  I don't think normal users should have to be
fishing around in hidden directories they probably don't even know exist.  If
they are, then I think some other solution is required, such as offering to
auto-import from competing products.
BTW, putting the check for this at the bottom of the generated directory menu
seems wrong to me; unintuitive, yet easy to hit by accident.  If someone adds it
(and I can't commit any of my team's engineering time for that), I think it
should be a easily clickable, since you'll typically toggle it both ways.
This is the generic file picker, right? We're no longer talking about a file
picker just for bookmark management.

The generic file picker must be able to see *every* file available to the user.

Don't presume to lump dot files in with the MacOS hidden file, it's not the same
thing. Dot files are a convenience to the user. The feature allows users to hide
files and directories from regular listings. However, Unix users learn to view
those files very shortly after they learn how to show detailed listings.

For one thing, folks I know routinely have a backup of important files in a
.backup or somesuch. I'd certainly have resume.html hiding their.

Having the program (and not the installer!) convert other bookmark files and
address lists is fine, but that a separate function. And you'd still better be
able to find the bookmark file. I might have moved it to .netscape.old...
Yes, this is the generic filepicker. However, I don't agree that .files are
primarily a convenience for the user, so much as a way for the system and apps
to hide files that end users shouldn't usually need to see, and aren't normally
the object of commands.  Many Unix users are advanced enough to be aware of them
and use them, which may also be true to a lesser extent on Windows and even Mac.
 That doesn't mean that an application intended for end users "must" show them.
 User that are savvy about them can always open them from the command line or
rename them to be visible, or type the path in the filepicker, which works just
fine right now.  This just doesn't fit our profile of things we can work on in
the current release cycle, although someone else could certainly do the work and
submit it to drivers.
>Many Unix users are advanced enough to be aware of them
>and use them

That doesn't mean we're in love with having to work around deficiencies in the
apps we use.

Deciding to hide things in Unix isn't advanced activity. In Mac and Windows you
need a special app to set a bit somewhere. In Unix it's just '.' in front of the
name. End users do this. 


Blocks: 104166
*** Bug 105866 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla0.9.9
Peter Trudelle wrote:
> This is starting to smell like feature creep to me.  I doubt we have much real
> user need for this in the product; nobody has offered any typical end-user
> scenarios where this feature would be needed.

Let me give you an example that I have run into: The standard UNIX file for
storing your email signature is ~/.signature, and that's where I have it. I
wanted to setup this in the Mail/News setup, and browsed for it in the
filepicker. Then I noticed it didn't show dotfiles. So instead of browsing for
it I had to type in the path by hand.
->enhancement/untargetted, adding nsbeta1 keyword to get triage team to look at
it (can't commit to doing the work without that)
Severity: normal → enhancement
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → ---
*** Bug 118472 has been marked as a duplicate of this bug. ***
end-user scenario that I just ran into:  I wanted to save an image as my desktop
background.  The  expected procedure for this is to  right click on the image
and do Save as, and then drop it in ~/.enlightenment/backgrounds, but I couldn't
find the .enlightenment directory.  I briefly considered ln -s it to a visible
directory, but decided that this would be a hastle and add to the clutter of my
home directory. I then hit upon the solution of typing in the whole path.  The
problem with this is that a) I wasn't completely sure it would work even as I
was doing it b) I wasn't completely sure of the exact path I wanted(ie was it
background or backgrounds?) so I had to go to a terminal to figure out the exact
path.

I like the checkbox idea, I think that is the way to go.  As for users not
usually interacting with .* files, besides this example what about .login,
.logout, .forward, .alias, .<shell>rc...(though I am not suggesting that a user
would ever want to access these files from within mozilla, it is still a precedent)
Another end user scenario:

I routinely setup my home page to be my bookmarks file. I can't do this with the
file picker since I can't see the ~/.mozilla directory. I can either type it in
manually or create a soft link from a visible directory.

I sorely miss the ability to show all files - including . files. This could
esily be fixed when I select 'All Files (*) from the the 'Files of Type' drop
down menu. An additional check box is not required. For the real purists perhaps
an additional item in the drop down list called 'All + Hidden files'.

The bottom line - I don't have this issue with any other Unix app and I don't
see why Mozilla has to be the odd one out. I thought the idea was to have
mozilla appeal to the broadest range of users. In its current form the
filepicker (and several other mozilla features) only appeal to the basic novice
user. Having used Netscape since the very first version and the original Mosaic
in its early alpha days, it is dissapointing to see how several advanced
features from those versions have yet to make it into mozilla.

For the purists that don't want to clutter dialogs and menus for novice users
while still supporting intermediate and advanced users - take a page from
Microsloth's book - offer an option for Basic, Intermediate and Advanced user
modes which alters just how much a user will see on the menus and dialogs.
Peter Trudelle, do you need more end-user scenarios than the ones we have
already provided? Here is another one:

At my university we should place files in ~/.html to make them automagically
show up as our webpages, and I think this is sort of standard for unix systems.
Instead of being able to browse for it I had to type it in manually. A novice
user of mozilla and UNIX would not even realize that the directory is there.

Peter, do you still think it is feature creep?
Summary: Linux filepicker or file:// view doesn't show hidden directories or files → Linux filepicker or file:// view doesn't show hidden directories or files (dotfiles)
It still has a whiff of feature creep around it (regular expressions, UI modes
and such), but the scenarios here are compelling.  I'd be okay with adding
something simple, such as a discrete checkbox.  File view considerations should
be kept separate though, this bug only applies to the filepicker.  How much
time/risk would be involved?  Is anyone able to attach a patch? I'd be happy to
pay Brian to review and integrate, but I doubt I could authorize anything
non-trivial or risky.
The good news here is that in the latest rewrite of the filepicker backend, I
built in support for a "show hidden files" mode, and the ability to switch
to/from that mode on the fly.  So, the frontend work here should be pretty
trivial, once we decide on an appropriate UI.
I'd agree that regexps are non-trivial, though I think they'd still be nice in a
full featured file-picker. But the real issue is unix dot files. As there
appears to be a backend solution, I'd say a checkbox would be good enough to
close this issue. The other stuff could then be moved into the realm of "when
someone is sufficiently motivated to submit a patch."
Okay Brian, if you or someone else can add this in 0.9.9, then it can still make
moz1.0 and MachV, otherwise it may have to be treated as an exception. 
->0.9.9/P2/nsbeta1+
Keywords: nsbeta1nsbeta1+
Priority: P3 → P2
Summary: Linux filepicker or file:// view doesn't show hidden directories or files (dotfiles) → Linux filepicker doesn't show hidden directories or files (dotfiles)
Target Milestone: --- → mozilla0.9.9
Nominating for nsbeta1 triage.
Keywords: nsbeta1
Blocks: 124456
Attached patch patchSplinter Review
Comment on attachment 69005 [details] [diff] [review]
patch

sr=jag

Check if you really need that pack="end".
Attachment #69005 - Flags: superreview+
checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
With 2002-02-12-06 on Linux I can't scroll quiet all the way down with the
scrollbar. The scrollbar stops about 0.5 centimeters before it has reached it's
bottom position. This happens with this new option on or off, so it might have
been in the dialog before this.

Can someone verify?
Why were the alignments to the  buttons changed from right to center? 
(At least Linux has default right-aligned as of 2002021121)
And now I can't reproduce (at least not all the time) what I said in comment 54.
kiko@async.com.br, can you explain what you mean?   The OK and Cancel buttons
should still be on the right side of the dialog, as seen in:

http://homepage.mac.com/bryner1/.cv/bryner1/Public/fp%2Dhidden2.png-link.png

Comment on attachment 69005 [details] [diff] [review]
patch

>+<hbox class="dialog-button-box" align="center" pack="end">
>+  <checkbox label="&showHiddenFiles.label;" oncommand="toggleShowHidden();"
>+            flex="1" align="left"/>
>+  <button dlgtype="accept" class="dialog-button"/>
>+  <button dlgtype="cancel" class="dialog-button"/>
>+</hbox>

Sorry, never mind really. I don't know XUL's positioning rules very well, but I
was under the assumption that, from the code, the button would inherit the 
parent's alignment, and thus, both buttons would be centered. I guess the XUL
for
the buttons already defines them as right-aligned (which strikes me as odd?).
(My experience being with GTK+'s pos model, which isn't exactly different from
XUL's, but different enough to cause confusion like this)
The buttons aren't specifically right aligned, but they don't have any flex set.
 The checkbox flexes, with left alignment, so it takes up all of the extra space.
vrfy'd fixed with 2002.02.21.08 comm bits on linux rh7.2.
Status: RESOLVED → VERIFIED
removed the item for this bug from the release notes for 0.9.9 and beyond,
because the bug is fixed now. Let me know if you think the item should be 
re-added.
Looks good to me. Thanks folks. It's nice and fast too.
BTW, I'm using it in RH6.2.
You need to log in before you can comment on or make changes to this bug.