Closed Bug 83662 Opened 23 years ago Closed 23 years ago

Can't select first item in any folder in FilePicker

Categories

(Core :: XUL, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: gillesd, Assigned: bryner)

References

Details

(Whiteboard: vrfy on next branch build)

Attachments

(1 file)

Create New Message.
Select the Attach button.
Select a folder (preferrably with no subfolders) and pick the first file in the
list.

On my version (linux, mozilla build 20001060106), the Open button is greyed out.
Furthermore, the name of the file is not updated FOR THE FIRST FILE in the list,
ONLY. This is a pretty weird bug, but I've been able to reproduce it on another
machine as well with a build from 4 days ago.
Does this happen only for attachments?  What about using the "Open" menuitem?  
Could this be a filepicker bug?
Yup Boris, didn't think of that. You were right: From the browser, we cannot
open the first file in a list.
update summary and ressign to right component
Assignee: ducarroz → pchen
Component: Composition → XP Apps
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: sheelar → sairuh
Summary: Can't use first item in any folder as an attachment → Can't select first item in any folder in FilePicker
Reassigning to bryner
Assignee: pchen → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
accepting for 0.9.3.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
Component: XP Apps → XP Toolkit/Widgets
QA Contact: sairuh → aegis
i see this too [2001.05.31.08 comm]. workaround: click on another file in the
file picker, then click the 1st file --you can then open the 1st file [the Open
button becomes enabled, too].
QA Contact: aegis → sairuh
Sairuh(se), your workaround doesn't work on our machines: if you watch closely
for the name of the file, it remains whatever was the latest you clicked on,
EXCEPT the first one. The only real workaround I found was to actually TYPE in
the filename. Gilles
Oh, BTW, Brian, 0.9.3? Can't it be done for 0.9.2? This seems rather important
(as I said previously, the only workaround is to type in the name of the file).
Here at OEone, this is quite important...
gilles, thx for the clarification! i doublechecked, and you're right: even
though it seems that the 1st file is selected [after clicking another one], it
won't load [unless you explicitly type in its name].
Target Milestone: mozilla0.9.3 → mozilla0.9.2
Is the first file in the directory you're using a symlink?  That's the only case
where I'm seeing what you describe.
no, when i saw this it was with a text file.
What's a "symlink"? I see this problem with all types of file (images, text, 
html, etc.)  Hope I answered correctly?
('symlink' == Unix symbolic link [see ln(1)].)
Attached patch patchSplinter Review
r=jag
sr=blizzard
Blocks: 83989
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified, Linux, 2001060508
Status: RESOLVED → VERIFIED
a=blizzard on behalf of drivers for 0.9.1
checked into 0.9.1 branch.
chad, i take it you verified this using a trunk build?

since bryner only recently checked it into the branch, i'm adding note to vrfy
this when the next branch build comes out... /me wishes there was some way to
set this back to resolved without having to reopen, ah well...
Whiteboard: vrfy on next branch build
Verified on the branch.  2001060606
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: