The first param is currently a nsIWidget*, which is difficult (impossible?) to obtain. It should be a more convienient window interface. Note: The only platforms that are using this now is Windows. In the Window's implementation of nsFileWidget::Create, the aParent window is used to get a file handle like this: mWnd = (HWND) ((aParent) ? aParent->GetNativeData(NS_NATIVE_WINDOW) : 0); It would be nice if this parent window was an nsIDOMWindow so it could be used from Java Script. GetNativeData() would have to be implemented by nsIDOMWindow. This is very important for proper modality/Z-order behavior in Windows.

cmanske's proposed change sounds reasonable to me but I need input from people more familiar with this isue than I. Bueller?

Bueller? Bueller? Still looking for input on cmanske's proposal. Since it only affects Win32 I really need some feedback from someone more familiar with that platform.

I'm with Charley 100%. nsIDOMWindow should be the preferred "window" argument type whenever possible, particularly in this case.

Do we have to bring this up at one of Brendan's architecture meetings?

If you can easily get the native window handle from a nsIDOMWindow all we need to do is add a nsFileWidget::Create method that takes a nsNativeWidget as the parent parameter. I'm suprised that you would be able to get to a native window handle without going through a nsIWidget however.

I would rather not see Widget interfaces become more and more reliant on nsIDOM interfaces.

We still need a resolution on this but it's going to be post beta

I don't understand why this is so difficult!

dividing up phillips bugs, he no longer works here

*** Bug 10000 has been marked as a duplicate of this bug. ***

Just clarifying the summary and adding some more detail on the problem... The problem stems from the fact that nsIFileWIdget was originally implemented as part of the file picker form widget as a wrapper to bring up the OS native file picker dialog. When called from this context there was always a nsIWidget* available to refer to as the parent window. Now that the file picker is being accessed from other places in the code base, or from JavaScript, we don't necessarily have available a nsIWidget* to pass in. On a platform such as Windows this presents a problem as there is no z-ordering enforced between the file dialog and the parent. Worse is that the file picker dialog will show up as a seperate item in the task bar.

Can we solve this problem by adding a method to nsIDOMWindow to get the nsIWidget the nsIDOMWindow is holding onto through JavaScript. We can't make the nsIFileWidget take a nsIDOMWindow as it's parent because it lives in the widget module which does and should not have any dependencies on the DOM module. CC'ing Vidur for the feedback on the modification to nsIDOMWindow. Added vidur to CC list and for this bug.

nsIWidget isn't even a script-friendly interface. No, getting a nsIWidget is not a DOM-like thing to do. There are native code ways of getting the widget (albeit through several QIs and getters). Sounds like you need a script accessible wrapper that is aware of DOM interfaces.

It seems that the only code that actually uses nsIFileWidget is the implementation of various higher-level "file picker" interfaces. For example, I use nsIFileSpecWithUI exclusively (it is fully scriptable and has some nice features not offered elsewhere). There may be some other residual users of nsIFileWidget, but they could likely change to use something else (either nsIFileSpecWithUI or its replacement(?), nsIFilePicker, which is under development). I could live with closing this WONTFIX.

pav's nsIFilePicker is going to replace these interfaces post BETA1 so re- targetting milestone and re-assigning to pav

Whoever is implementing nsIFilePicker, be sure it accomodates what Composer needs: We must be able to set the filter types (allowable file extensions), set the window title (caption), set the initial directory, and set the initial filename. See nsEditorShell::GetLocalFileURL in mozilla/editor/base/nsEditorShell.cpp for details -- that is where we are currently using nsIFileWidget to put up a dialog to pick files.

->jrgm

marking fixed. there are seperate bugs for the remaining places that need to be converted to using the new file picker apis

verified fixed. (Follow the trail in bug 36789[FIXED], bug 39234, bug 37175[FIXED] for remaining fixes).