245554 - Allow nsIFilePicker.show to be called with a null parent

Status: NEW

(Core :: Widget, defect, P5)

Description

[timeless]

I'm trying to write testcases and as stated earlier, i can't create a dom window
because no one exposed the window creator even though i asked for it a few years
ago (say spring 2002?).

Even if I could create a window, having to do so is fairly annoying, it doesn't
make sense for xpcshell to create a window just so it can toss up a file picker
which has a parent.

This makes testing things like the fix to bug 245544 fairly hard.

a nice soul offered to work on the fix, but asked how to test it. I explained:
to actually test it you'd need to setup getservice to be able to fail
which isn't worth the effort
actually, i might be able to contrive a fairly easy way to make it fail

edit components/compreg.dat
look for a line like:
@mozilla.org/intl/stringbundle;1,{d85a17c1-aa7c-11d2-9b8c-00805f8a16d9}
remove it
save the file
make it readonly
run mozilla

the problem is that running mozilla is quite likely to bail long before the code
is reached, so the test won't work.

now if xpcshell could create a filepicker, then testing this is simple. follow
the steps above, but instead of running mozilla, you run xpcshell

fp=Components.classes["@mozilla.org/filepicker;1"].createInstance(Components.interfaces.nsIFilePicker);
fp.appendFilters(1);
fp.show();

It turns out that this example isn't perfect, the call to show isn't needed to
crash (since you crash calling appendFilters). But a case where it is needed
could exist.

more importantly you could have a script which wants to toss up a filepicker and
actually use the user's input to do something. and it won't be able to.

this is a regression, it happens to be among a few changes which is
significantly harming some of our commercial tasks since we have to retool to
test and play with the trunk. it also makes xpcshell test harnessing a lot
harder than it should be, and until recently i'd been writing a lot of xpcshell
based testcases.

note that the old code *did* work on windows and I did use it (a lot).

Comment 1

[Johnny Stenback (:jst)]

Feel free to make the filepicker code work with a null parent again if there's
no other obvious way to do what you're trying to do...

Comment 2

[Jonathan]

rg "nsIFilePicker.show" finds nothing

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 4

[Neil Deakin]

It's nsIFilePicker::Init() now, but I don't think this is worth spending time on.