293187 - Need global getSpecialFolderKey

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Ben Basson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050402 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050402 Firefox/1.0+

The function getSpecialFolderKey is defined several times in Firefox (the
download manager and download pref related code to name but two uses). 

The problem is that it is defined within other functions and is not directly
accessible without overlaying lots of core code that I have no intention of using.

It would be preferable (at least to me) and probably logical to have
getSpecialFolderKey or an equivalent as a global Firefox function so that it can
be used by functions other than those intended.

Normally I would simply replicate the code in cases like this, but ifdefs are
used to select the appropriate OS for the return value, so I either have to
implement OS checking code or overlay code that I don't want.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ben Basson]

If API changes aren't meant to occur after Firefox 1.1a or 1.8b2, would this
need to be fixed sooner rather than later? Nominating for both, but apologies in
advance if either (or both) aren't appropriate blocking targets.

Comment 2

[Nickolay_Ponomarev]

Here's where the function is declared:
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/downloads.js#750
http://lxr.mozilla.org/seamonkey/source/browser/components/preferences/downloads.js#93
http://lxr.mozilla.org/seamonkey/source/mail/components/preferences/downloads.js#93

Interestingly enough, it differs a little (in mozapps variant, there's also a
ifdef XP_BEOS).

You generally don't get far by setting blocking? flags on a milestone like
1.8b2m which is going to be released soon on such a non-critical bug. I'd try to
catch someone on IRC instead.

Comment 3

[Mike Connor [:mconnor]]

this isn't a blocker.

the problem first off is "where do you put this" since it basically has to live
in toolkit.  It can go into the next alpha if there's an answer.

Comment 4

[Ben Basson]

(In reply to comment #3)
> this isn't a blocker.

I thought as much (since it's nowhere near that level of importance) but wanted
to clarify, since it's API-related. blocking1.1 was a silly nomination, not sure
what I was thinking.

> the problem first off is "where do you put this" since it basically has to live
> in toolkit.  It can go into the next alpha if there's an answer.

Perhals globalOverlay.js?

Comment 5

[Ben Basson]

Mike, will you consider this for 2.0 as part of your "make useful toolkit functions" scheme?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

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

Comment 7

[Mike Conley (:mconley) (:⚙️)]

getSpecialFolderKey appears to be basically useless in mozilla-central, according to dxr:

http://dxr.mozilla.org/search?tree=mozilla-central&q=getSpecialFolderKey&redirect=true

Filing 860998 to get that removed.