If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux - Trunk [@ nsFilePicker::ShowW]

VERIFIED DUPLICATE of bug 268311

Status

()

Core
XUL
--
critical
VERIFIED DUPLICATE of bug 268311
13 years ago
12 years ago

People

(Reporter: Daniel Barrett, Assigned: jag (Peter Annema))

Tracking

({crash, topcrash})

Trunk
x86
Windows XP
crash, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707

This code works on Linux but crashes Mozilla 1.7 in Windows XP:

var nsIFilePicker = Components.interfaces.nsIFilePicker;
var fp =
Components.classes["@mozilla.org/filepicker;1"].createInstance(nsIFilePicker);
fp.init(window, "my title", nsIFilePicker.modeGetFolder);
fp.displayDirectory = null; // this causes the problem
// Windows crash happens on the next line
var res = fp.show();


Reproducible: Always
Steps to Reproduce:
1. Get "UniversalXPConnect" privileges. 
2. Run the code above.

Actual Results:  
Mozilla crash and exit.

Expected Results:  
If the null is acceptable, open the filepicker. If not, throw an appropriate
exception.

Updated

13 years ago
Severity: normal → critical
Keywords: crash

Comment 1

13 years ago
this sounds familiar, didn't we have this problem on trunk for a bit?

Updated

13 years ago
Summary: filepicker with null displayDirectory crashes show() on Windows, works on Linux → filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux

Comment 2

13 years ago
iirc darin tripped over this with his ftp upload patch.

Comment 3

13 years ago
The problem here is that mDisplayDirectory is created in the constructor, and
then assumed to be there when it is used in Show.

If a SetDisplayDirectory comes in and wipes it out, we crash.

Instead of initializing mDisplayDirectory in the constructor, maybe we should
initialize it at the beginning of show if it is null?
Status: UNCONFIRMED → NEW
Ever confirmed: true
fwiw, this is the number 6 trunk topcrash, according to
http://talkback-public.mozilla.org/reports/mozilla/Trunk/Trunk-topcrashers.html
Keywords: topcrash
Summary: filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux → filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux [@ nsFilePicker::ShowW]
although that topcrash may be a regression; user comments say it's from save
link target as. seems to have appeared on 101107 - two days after Bug 160454, if
I'm reading this date format right. hm... the code doesn't really look like this
part has changed, though...

Comment 6

13 years ago
We definitely should just fix this once and for all.

Can someone give me a real JS component I can use to recreate?

thanks

Comment 7

13 years ago
(In reply to comment #5)
> although that topcrash may be a regression; user comments say it's from save
> link target as. seems to have appeared on 101107 - two days after Bug 
160454, if
> I'm reading this date format right. hm... the code doesn't really look like 
this
> part has changed, though...

Does seem to have broken (presumeably with bug 160454) so will look into it.
Blocks: 267406
Blocks: 160454
Depends on: 268311

Comment 8

13 years ago
Latest Talkback data suggests this crash might have gone away after 11/8
MozillaTrunk builds (bug 267406 was fixed that day).  Does anyone know if this
particular crash is still around in any form?  Or should we mark this fixed?
Summary: filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux [@ nsFilePicker::ShowW] → filepicker with null displayDirectory crashes show() on Windows and OS/2, works on Linux - Trunk [@ nsFilePicker::ShowW]
> Does anyone know if this particular crash is still around in any form?

Yes.  That bug checked in a workaround for this bug in the save as code (it no
longer sets displayDirectory to null).

This bug still needs to be fixed in the relevant toolkits.

Comment 10

13 years ago
(In reply to comment #9)
> This bug still needs to be fixed in the relevant toolkits.

What is your opinion of comment #3 "...maybe we should initialize it at the
beginning of show if it is null?"

... or have the show method assert where appropriate?
I don't have any opinions on fixing this; the toolkits involved are not ones I'm
particularly familiar with.
looks like this was fixed in bug 268311?

*** This bug has been marked as a duplicate of 268311 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Updated

13 years ago
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsFilePicker::ShowW]
You need to log in before you can comment on or make changes to this bug.