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

VERIFIED FIXED in M15

Status

()

P2
major
VERIFIED FIXED
20 years ago
18 years ago

People

(Reporter: cmanske, Assigned: pavlov)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M7

Updated

20 years ago
Target Milestone: M7 → M8

Comment 1

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

Updated

19 years ago
Target Milestone: M8 → M9

Updated

19 years ago
Severity: major → critical
Priority: P3 → P2

Comment 2

19 years ago
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.

Comment 3

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

Updated

19 years ago
Target Milestone: M9 → M10

Comment 4

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

Updated

19 years ago
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.

Comment 6

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

Updated

19 years ago
Target Milestone: M11 → M14

Comment 7

19 years ago
We still need a resolution on this but it's going to be post beta
(Reporter)

Updated

19 years ago
Blocks: 13164

Updated

19 years ago
Blocks: 10000
(Reporter)

Comment 8

19 years ago
I don't understand why this is so difficult!

Comment 9

19 years ago
dividing up phillips bugs, he no longer works here

Comment 10

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

Updated

19 years ago
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

Comment 11

19 years ago
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.

Comment 13

19 years ago
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.

Comment 14

19 years ago
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.

Updated

19 years ago
Whiteboard: may turn out to be a WONTFIX in favor of nsIFilePicker

Comment 15

19 years ago
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
(Reporter)

Comment 16

19 years ago
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.
(Assignee)

Updated

19 years ago
Depends on: 26480
->jrgm
QA Contact: sairuh → jrgm
(Assignee)

Updated

19 years ago
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
(Assignee)

Updated

19 years ago
No longer depends on: 26480
(Assignee)

Updated

19 years ago
Depends on: 26480
(Assignee)

Updated

19 years ago
Depends on: 24625
No longer depends on: 26480
(Assignee)

Updated

19 years ago
Whiteboard: 3 days for all platforms
(Assignee)

Updated

19 years ago
Target Milestone: M16 → M15
(Assignee)

Updated

19 years ago
Blocks: 3025
(Assignee)

Updated

19 years ago
Blocks: 24719
(Assignee)

Updated

19 years ago
Blocks: 24731
(Assignee)

Updated

19 years ago
Blocks: 33062
(Assignee)

Updated

19 years ago
Whiteboard: 3 days for all platforms → 2 days to rip through everyones cpp and js code that brings up a file picker
(Assignee)

Updated

19 years ago
No longer blocks: 24731
(Assignee)

Updated

19 years ago
No longer blocks: 24719
(Assignee)

Updated

19 years ago
No longer blocks: 3025
(Assignee)

Comment 18

19 years ago
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
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 19

18 years ago
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.