nsIFilePicker (widget) returns a nsIURI (necko)

NEW
Unassigned

Status

()

--
minor
17 years ago
9 years ago

People

(Reporter: alecf, Unassigned)

Tracking

(Depends on: 1 bug, {embed, topembed-})

Trunk
embed, topembed-
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
We have a wierd dependency between widget and necko: if you are a consumer of
nsIFilePicker, you have to pull in necko because nsIFilePicker returns an nsIURI.

I have two ideas, looking for input:
- change nsIFilePicker to return an nsIFile or nsILocalFile
- move nsIFilePicker into xpfe somewhere.

I prefer the first option (use nsIFile)
(Reporter)

Updated

17 years ago
Blocks: 100107
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6

Comment 1

17 years ago
yea, option #1 seems to make sense, though, even after doing that, I think we're
still bound to necko (bugzilla 100212 should be a blocker for this bug if we go
w/ option #1?).
(Reporter)

Updated

17 years ago
Priority: -- → P2
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Reporter)

Comment 2

17 years ago
I'd really love to fix this, but it's just not high on the list!
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Reporter)

Comment 3

17 years ago
pushing out non-critical bugs past moz 1.0
Target Milestone: mozilla0.9.8 → mozilla1.1

Updated

17 years ago
Keywords: topembed

Comment 4

17 years ago
topembed-
- by triage team (cofmann, cathleen, marcia)
Keywords: topembed → embed, topembed-
(Reporter)

Updated

17 years ago
Priority: P2 → P3
(Reporter)

Comment 5

17 years ago
woah, 1.1 came up quick. Throwing these bugs over to 1.2.. little or no work has
been done and there is no way that these bugs can be fixed in 1.1.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
(Reporter)

Comment 6

16 years ago
ugh, this is going to be a pain to fix (its all JS stuff) and with no real gain
for now. Moving out
Blocks: 106686
No longer blocks: 100107
Target Milestone: mozilla1.2alpha → Future
for the js consumers:

var ioService = Components.classes["@mozilla.org/network/io-service;1"]
ioService = ioService.getService(Components.interfaces.nsIIOService);

var fileURL = ioService.newFileURI(fp.file).QueryInterface
(Components.interfaces.

I'm using this for http://bugzilla.mozilla.org/show_bug.cgi?id=121122

how many js consumers are there?
(Reporter)

Comment 8

16 years ago
most JS consumers want the URL string, so really they should be using
ioService.getURLSpecFromFile()

However, after bug 166792 is fixed, this will be available from the
nsIFileProtocolHandler

for example, here's the first patch from attachment 97922 [details] [diff] [review]

+      var fileHandler = XPCU.QI(ioService.getProtocolHandler("file"),
"nsIFileProtocolHandler");
+
+      var url = fileHandler.getURLSpecFromFile(file);
 
-      var url = ioService.getURLSpecFromFile(file);

(slightly different in that it gets the url string, but that is often what JS
consumers want)
ok, I'll do it your way in the file picker / compose bug.

thanks for the info.

Updated

9 years ago
Severity: normal → minor
Status: ASSIGNED → NEW
Depends on: 167282
OS: Windows 2000 → All
Priority: P3 → --
Hardware: x86 → All
Target Milestone: Future → ---

Updated

9 years ago
Assignee: alecf → nobody
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.