46237 - filepicker intermittantly won't open files

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[R.K.Aa.]

linux 2000-072113

More often than not, filepicker don't want to open a file.
When OK is clicked, this appears in console instead.
JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80520001 [nsILocalFile.parent]"  nsresult: "0x80520001 (<unknown>)"  location:
"JS frame :: chrome://global/content/filepicker.js :: onOK :: line 117"  data: no]


Some files DO open, however, and the error is 100% reproducable for the files
that won't open (while the files that WILL open, always open.)

Haven't found out what makes these files differ.
It is unrelated to doctype or filemode.

Comment 1

[R.K.Aa.]

typo...prolly more :)

Comment 2

[Blake Ross]

reassigning to bryner

Comment 3

[Brian Ryner (not reading)]

Can you insert the following just before line 117 in filepicker.js:

dump("file.path="+file.path+", file.parent="+file.parent+"\n");

and give me the output on a file that won't open?

Thanks.

Comment 4

[R.K.Aa.]

It didn't do a thing.
I'd like to test this with a new build, but all the directories at
ftp://ftp.mozilla.org/pub/mozilla/nightly/ created after the 21st are empty, or
just seem to contain empty subdirectories.
An error? There are now 10 new but seemingly empty directories at the ftp site.

Comment 5

[Brian Ryner (not reading)]

It should have done something, if you put it at the right place.  Look on the
console for "file.path=(...). file.parent=(...)" when you click OK.

Comment 6

[R.K.Aa.]

same thing with 2000-072408
I pasted in the line you suggested in filepicker.js
Here is how line 114 and outward looks in filepicker.js after i inserted that
line - the numbers are "on me":

114:  switch(filePickerMode) {
115:  case nsIFilePicker.modeOpen:
116:    if (isFile) {
117: dump("file.path="+file.path+", file.parent="+file.parent+"\n");
118:      retvals.directory = file.parent.path;
119:      ret = nsIFilePicker.returnOK;

Comment 7

[Brian Ryner (not reading)]

And still no output?  That is strange.  If you can give me anything else to go
on it would be great... I've never seen this bug.

Comment 8

[R.K.Aa.]

sniffed a little further on this one:

The error happens if i try to open html files residing in my homedir.
There are heaps of subdirectories there also.

The error does NOT happen if i direct filepicker into a subdirectory without
additional directories, but only files.

The dump gives NO output when the js error occurs, and it does print path etc.
like expected, when there is no error.

So somehow filepicker doesn't see the files as files in my homedir.
The directories there somehow confuse it - perhaps it sees html files there as
directories as well? There is nothing wrong with the files as such - they open
just fine in NC4.7 and used to open just fine a week ago or less also with mozilla.

Comment 9

[Brian Ryner (not reading)]

If you can, try reverting this change:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/components/filepicker/res/content&command=DIFF_FRAMESET&file=filepicker.js&rev1=1.23&rev2=1.24&root=/cvsroot

and see if it helps at all.  That's the only real change to the filepicker in
the last week.  Thanks.

Comment 10

[R.K.Aa.]

nope - reverting those changes only moved the js error to line 113
(the dump line you suggested earlyer is still left in file)

Comment 11

[R.K.Aa.]

well this sure is a weird one.
I tested 071820 build.
That had a bug where filename wasn't filled out, but doubleclicking file will
open it. And files open now too.
Then i quit the old build, and started 072408 again.
And that too could now open that file.

So i closed 072408 again, restarted it, deleted disk-cache (via preferences)
and the file could once again NOT be opened. (I.E. spawning the original js
error, (and no filepath prints).)

Comment 12

[R.K.Aa.]

error: the old build i tested was 071720! (not 071820)

Comment 13

[Peter Trudelle]

nominating for nsbeta3

Comment 14

[Brian Ryner (not reading)]

Do you think you can give me an 'ls -la' from a directory that shows this
problem (reduced down if possible).  I suspect this is some sort of problem with
the ordering of files and folders.

Comment 15

[R.K.Aa.]

i'll mail you the output (distrusting my file accesses here)
subject will be this bugs URL.

However - i'm starting to smell cache interference here..
Why should the file load when it's cached, but not otherwise?
Or is it that it simply loads FROM cache then? (and not the real file?)

Comment 16

[Brian Ryner (not reading)]

Unable to reproduce this with your instructions, sorry.

It's remotely possible that you're hitting on a tree bug, like 43459 (especially
if you usually drag the slider down).

Comment 17

[Peter Trudelle]

nsbeta3-, we can't hold for what we can't reproduce.  If we can get a
reproducible test case, we can renominate.

Comment 18

[R.K.Aa.]

Been on vacation for a week, and i can't reproduce this with 2000.073108
Files open OK in this build
Setting WFM, will reopen if i see it again.

Comment 19

[R.K.Aa.]

reopening. Same shit in build ID 2000-080208
Error slightly changed:
JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80520001 [nsILocalFile.parent]"  nsresult: "0x80520001 (<unknown>)"  location:
"JS frame :: chrome://global/content/filepicker.js :: onOK :: line 123"  data: no]


I'm not able to detect any pattern in when it triggers and not, really.
It doesn't matter whether i maneuver using scrollwheel mouse or dragging scrollbar.

Comment 20

[Brian Ryner (not reading)]

Can you change that section to:

    if (isFile) {
      var pFile = file.parent;
      dump("pFile="+pFile+"\n");
      retvals.directory = pFile.path;
      ret = nsIFilePicker.returnOK;

and give me the new error output?  Thanks.

Comment 21

[R.K.Aa.]

no change.

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

With the change listed, the error moves to the line "var pFile = file.parent;",
and nothing else prints other than the same error.

I see this as well, with bookmarks in my ~/src/mozilla_work/mozilla/dist/bin
directory.  It doesn't happen in /tmp.  Fresh pull 8/3/00, FreeBSD.

I'll attach an ls -la on the directory that fails.

Comment 23

[Randell Jesup [:jesup] (needinfo me)]

I should note that this happens pretty often to me.  I see it when trying to
import bookmarks.html.

I would consider this pretty important to fix for unixes.

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

Attachment: ls -la on the directory

Comment 25

[Brian Ryner (not reading)]

Hm, I don't suppose you have symlinks in your directory structure? (i.e. either
the directory you are in, or a directory above it, is a symlink).

Comment 26

[Brian Ryner (not reading)]

Can you also try adding:

dump("file.path="+file.path+"\n");

inside the if block (BEFORE any parent references) and give me that output too? 
Thanks.

Comment 27

[Brian Ryner (not reading)]

Good news! I finally saw this bug.  I've got a patch that seems to fix it,
although it needs thoroughly tested, so I'm attaching it here.

Comment 28

[Brian Ryner (not reading)]

Attachment: patch

Comment 29

[Colin Blake]

On OpenVMS M17 build I am seeing this problem all the time. I tried applying
the patch and I'm still seeing the problem.

Colin.

Comment 30

[Peter "jag" Annema]

Brian found a solution to this yesterday after some hunting on irc. I've whipped 
it up into a patch which I'll attach here.

Comment 31

[Peter "jag" Annema]

Attachment: [patch] fix and clean-up of onOK, please test

Comment 32

[R.K.Aa.]

This looks very promising :)

With the patch, filepicker see the files as files and hasn't failed me today.
One file (big) used to fail more often than others, and now seems to open each
time. But given the nature of this bug, perhaps give it a little longer before
assuming the fix is 100%. I'll test and test and report back.

When testing: Keep in mind that a file that has already been opened and is
cached, seems to "always" open. Have to delete all cache (via prefs), the
restart moz, to test for real.

Comment 33

[R.K.Aa.]

I haven't seen the bug for a while, even without using the patch (or was it
checked in?) Setting this WFM.