Closed Bug 6783 Opened 26 years ago Closed 25 years ago

[feature] use nsIFilePicker to replace nsIFileWidget, nsIFileSpecWithUI, etc

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cmanske, Assigned: pavlov)

References

(Depends on 1 open bug)

Details

(Whiteboard: 2 days to rip through everyones cpp and js code that brings up a file picker)

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.
Status: NEW → ASSIGNED
Target Milestone: M7
Target Milestone: M7 → M8
cmanske's proposed change sounds reasonable to me but I need input from people more familiar with this isue than I. Bueller?
Target Milestone: M8 → M9
Severity: major → critical
Priority: P3 → P2
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.
Target Milestone: M9 → M10
Do we have to bring this up at one of Brendan's architecture meetings?
Target Milestone: M10 → M11
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.
Target Milestone: M11 → M14
We still need a resolution on this but it's going to be post beta
Blocks: 13164
Blocks: 10000
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. ***
Summary: Change 1st param of nsIFileWidget::GetFile to use a generic parent window → 1st param of nsIFileWidget::GetFile needs to be a generic window reference
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.
Whiteboard: may turn out to be a WONTFIX in favor of nsIFilePicker
pav's nsIFilePicker is going to replace these interfaces post BETA1 so re- targetting milestone and re-assigning to pav
Assignee: sdagley → pavlov
Status: ASSIGNED → NEW
Target Milestone: M14 → M15
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.
Depends on: 26480
->jrgm
QA Contact: sairuh → jrgm
Severity: critical → major
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Summary: 1st param of nsIFileWidget::GetFile needs to be a generic window reference → [feature] use nsIFilePicker to replace nsIFileWidget, nsIFileSpecWithUI, etc
Whiteboard: may turn out to be a WONTFIX in favor of nsIFilePicker
Target Milestone: M15 → M16
No longer depends on: 26480
Depends on: 26480
Depends on: 24625
No longer depends on: 26480
Whiteboard: 3 days for all platforms
Target Milestone: M16 → M15
Blocks: 3025
Blocks: 24719
Blocks: 24731
Blocks: 33062
Whiteboard: 3 days for all platforms → 2 days to rip through everyones cpp and js code that brings up a file picker
No longer blocks: 24731
No longer blocks: 24719
No longer blocks: 3025
marking fixed. there are seperate bugs for the remaining places that need to be converted to using the new file picker apis
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified fixed. (Follow the trail in bug 36789[FIXED], bug 39234, bug 37175[FIXED] for remaining fixes).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.