264889 - Firefox Desktop Namespace Icon

Status: RESOLVED WONTFIX

(Firefox :: Shell Integration, enhancement)

Description

[Ayo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 StumbleUpon/1.998
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 StumbleUpon/1.998

There was a good thread on mozillazine that chronicles MSI deployment and most
notably a Desktop namespace icon for firefox. This icon would increase Mozilla's
Windows desktop integration by making Firefox appear integrated with Windows
rather than simply an alternative third party application.  

The comments about this thread can be viewed at:
http://forums.mozillazine.org/viewtopic.php?t=138033

I will try and work on the proper patches to apply to the tree but my knowledge
of XUL and the mozilla source is rather minimal.  This bug is to just 

Reproducible: Always
Steps to Reproduce:

Comment 1

[Ayo]

Attachment: VB Script to apply entries w/o needed paths

Comment 2

[Ayo]

Attachment: VB Script to remove entries w/o needed paths

Comment 3

[Ayo]

Attachment: Registry v5 entries to add namespace icons

Comment 4

[Jesse Ruderman]

Is a namespace icon what IE has?  If it is, I think this is a dup of bug 259830.

Comment 5

[Ayo]

This is bug is exactly the same concept except it uses the Firefox GUID for the
CSLID which is prefered and AFAIK it does allow you to drag and drop files to
the firefox icon.  The reason you can't drag and drop files to the IE icon is
because of the attributes set on the icon. 

Note that you can drag and drop files to the Recycle Bin, My Nreifcase, My
Computer, as well as to My Network Places.  The code provided includes much more
interpolability with various systems than the registry file attached in bug 259830

I've change the type of bug from Installer to OS Integration enhancement, to
follow suit with bug 259830.

Comment 6

[David Janes]

Yes I think this is a dupe of bug 259830

Comment 7

[Simon Paquet [:sipaq]]

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

Comment 8

[Michael]

I think it would be helpful if a COM object was created to give the icon drop
handling capabilities. Then the user can drag files onto the icon to be opened
by Firefox.

Comment 9

[Phil Ringnalda (:philor)]

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

Comment 10

[Phil Ringnalda (:philor)]

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

Comment 11

[David Janes]

If Firefox gets a desktop namespace icon then it'll also need a pref to
re-create it in case the user deletes it (as IE has).

There is currently an option for this in "Set Program Access and Defaults" in
Add/Remove Programs but IMHO it needs to be in the browser too.

Comment 12

[Ayo]

Comment #11 is correct there needs to be a pref in the options menu to remove
the icon.  The attached have the option to remove the icon on a per user basis.
 This key how a user can remove and re-add "My Documents, NetWork Places, My
Computer, etc."  I'm not a skilled XUL programmer but the registry entry that
would need to be toggled in order to remove and add the icon from within Firefox
is as follows:

For the XP Style Startmenu
"[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\ClassicStartMenu]"=dword:00000000

Ford the Classis Style Startmenu
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel]"{EC8030F7-C20A-464F-9B0E-13A3A9E97384}"=dword:00000000

a dword value of 1 adds the icon. 

The remove VB Script entry is there as to remove the namespace entries from the
registry if Firefox were to be uninstalled.  Again the entries provided in this
comment remove the icons per user which is ideal in a multiuser environment.

I haven't found a way to write the COM+ entires to allow drag and drop support
on this particular icon. If anyone has any information please share.

Comment 13

[Ayo]

In comment #12 I botched up the entries. The GUID for firefox must be specified
as follows.

Ford the Classis Style Startmenu
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\ClassicStartMenu]"{EC8030F7-C20A-464F-9B0E-13A3A9E97384}"=dword:00000000

For the XP Style Startmenu
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel]"{EC8030F7-C20A-464F-9B0E-13A3A9E97384}"=dword:00000000

a dword value of 1 adds the icon. Enables the icons where a dword value of 0
removes them.

Comment 14

[Michael]

Ayo, these sites might be of some help:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/shellinstobj.asp
http://www.virtualplastic.net/html/ui_shell.html
http://www.microsoft.com/mind/0399/faq/faq0399.asp
http://www.geocities.com/helmi79/software/software.html (UniDrop)

Comment 15

[Michael]

Well I've struggled to add drop support to the firefox icon. Below is the code
that uses the folder shortcut clsid so that files dragged onto the icon will be
moved to the firefox director. I can't find the clsid for shortcuts, so that the
files will open in firefox instead.

------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\InProcServer32]
@="shdocvw.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\Instance]
"CLSID"="{0afaced1-e828-11d1-9187-b532f1e9575d}"

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\Instance\InitPropertyBag]
"Attributes"=dword:00000015
"Target"="C:\Program Files\Mozilla Firefox"
------------------------------------------

Below is the code to make an entry in Folder Options to hide or show the desktop
icon. Does anyone know how to put the entry under customise desktop in display
properties where the other desktop icons that can be hidden are?

------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Firefox]
"RegPath"="Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\HideDesktopIcons\\NewStartPanel"
"Text"="Show Mozilla Firefox on Desktop"
"Type"="checkbox"
"ValueName"="{EC8030F7-C20A-464F-9B0E-13A3A9E97384}"
"CheckedValue"=dword:00000000
"UncheckedValue"=dword:00000001
"DefaultValue"=dword:00000000
"HKeyRoot"=dword:80000001
"HelpID"="shell.hlp#51150"
------------------------------------------

Comment 16

[David Janes]

Attachment: Add/Remove Programs

The option to show the icon on the desktop should go into Firefox Options
and/or "Set Program Access and Defaults" (see Screenshot). This is what IE
does.

Also it needs a right-click Properties option. Firefox has this functionality
as on Windows XP you can right-click "Internet" on the Start Menu and select
properties, it then opens Tools | Options. Don't know how this works though.
Ideally this should go into Control Panel too. That would be nice.

Also how did you generate the GUID?

Comment 17

[David Janes]

I've tried that reg file and on Win2k it doesn't seem to work.

This seems to be okay though:

------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}]
@="Mozilla Firefox"
"InfoTip"="Displays Web sites on the Internet"

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\DefaultIcon]
@="C:\\Program Files\\Mozilla Firefox\\firefox.exe,0"

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\LocalServer32]
@="\"C:\\Program Files\\Mozilla Firefox\\firefox.exe\""

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\shell]
@=""

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\shell\Internet
&Options]

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\shell\Internet
&Options\command]
@="C:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE -chrome
\"chrome://browser/content/pref/pref.xul\""

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\shell\Open &Home
Page]

[HKEY_CLASSES_ROOT\CLSID\{EC8030F7-C20A-464F-9B0E-13A3A9E97384}\shell\Open &Home
Page\command]
@="C:\\Program Files\\Mozilla Firefox\\firefox.exe"

------------------------------------------

Unfortunately I can't get it to default to Open Home Page.

As for a Control Panel item you're meant to create a .cpl file, but it's also
possible to create a CLSID for a Firefox Control Panel (which launches
C:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE -chrome
\"chrome://browser/content/pref/pref.xul\") and then add it to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace.

I think this goes to show that it needs to be added via an API call. Otherwise
you'll be asking for trouble.

Comment 18

[Michael]

>The option to show the icon on the desktop should go into Firefox Options
>and/or "Set Program Access and Defaults"

The registry entries for that is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\firefox.exe\InstallInfo]
"HideIconsCommand"="\"C:\\Program Files\\Mozilla
Firefox\\uninstall\\UninstallFirefox.exe\" /ua \"1.0PR (en-US)\" /hs browser"
"IconsVisible"=dword:00000001
"ReinstallCommand"="\"C:\\Program Files\\Mozilla Firefox\\firefox.exe\" -silent
-nosplash -setDefaultBrowser "
"ShowIconsCommand"="\"C:\\Program Files\\Mozilla
Firefox\\uninstall\\UninstallFirefox.exe\" /ua \"1.0PR (en-US)\" /ss browser"

At the moment running the uninstall file with those switches doesn't do anything
yet. They can be made to set the registry entries that Ayo specified to hide the
desktop icon. The "IconsVisible" entry also needs to be set so that when the
enable access box is checked or unchecked it will be remembered, currently since
this reg value doesn't change it stays checked all the time. The big problem I
have with this is that these entries only work on LOCAL_MACHINE and not
CURRENT_USER. Even though we can hide the shortcuts for the current user,
whether that box is checked or not affects all users which doesn't make sense.
Try it with Internet Explorer, disable access then log into a different user.
Then you will see that user still has access, which is good it should only be
per user, however the checkbox is unchecked.

I agree we should get those options working even with that limitation but most
users I know are more used to going to customise desktop to show or hide access
to IE, My Documents etc under WinXP.

>I've tried that reg file and on Win2k it doesn't seem to work.

The reason the reg file didn't work for you is it assumes the default location
of firefox is "c:\program files\mozilla.org\mozilla firefox" and for you it
should be "c:\program files\mozilla firefox". The script files provided are
better in that you don't need to change the paths. Unfortunately it currently
works only with Firefox 1.0PR, you will need to replace this line:

FIREFOX_EXE = Chr(34) & WShell.RegRead("HKLM\SOFTWARE\Mozilla\Mozilla
Firefox\1.0PR (en-US)\Main\PathToExe") & Chr(34)

with these two lines:

FIREFOX_VER = WShell.RegRead("HKLM\SOFTWARE\Mozilla\Mozilla Firefox\CurrentVersion")
FIREFOX_EXE = Chr(34) & WShell.RegRead("HKLM\SOFTWARE\Mozilla\Mozilla Firefox\"
& FIREFOX_VER & "\Main\PathToExe") & Chr(34)

So the script will work with any version and not just 1.0PR.

>Unfortunately I can't get it to default to Open Home Page.

This is a seperate problem, if you have a home page set then all you need to do
is simply to open firefox and it should come up. There is no command line
parameter for this.

>Also it needs a right-click Properties option.

The example files do it's called "options" currently in the context menu.

>Also how did you generate the GUID?

You use a utility like this one:
http://www.microsoft.com/downloads/details.aspx?FamilyID=94551F58-484F-4A8C-BB39-ADB270833AFC&displaylang=en

Comment 19

[David Janes]

I think you're getting the wrong idea.
I tried the first registry fragment from Comment #15, not the VBScript. This
didn't work in W2k, and the location was c:\program files\mozilla firefox.

Also the "Open Home Page" is the right-click option in Comment #17 to open
Firefox, as this is what it's called for the IE icon.
Nothing to do with the home page.

Comment 20

[Michael]

I have filed bug 288589 for Thunderbird's desktop icon.

NOTE: I apologise for my lengthy discussion with David can it be removed?

Comment 21

[Robert Strong (they/them - no direct email)]

Though I agree that having a namespace icon is a good thing I disagree with the
method being used... I threw together this hack well over a year ago and though
it does for the most part work the better method is to create a context menu
handler (e.g. winrar, outlook, etc. all do so) to accomplish this instead of
using registry entries as in the suggested solution.

Comment 22

[Frédéric Jeanbart]

(In reply to comment #21)
> Though I agree that having a namespace icon is a good thing I disagree with the
> method being used... I threw together this hack well over a year ago and though
> (the better method is to create a context menu
> handler (e.g. winrar, outlook, etc. all do so) to accomplish this instead of
> using registry entries as in the suggested solution.

I totally agree: the less we use the Windows registry facility (particularly
when assigning a GUID to Firefox, and thus for all its "operational"
functionalities like launching, profiling, configuring), the less Firefox would
be "compromisable". For example, I've noticed that a XUL application could work
out of the navigator's soap-box (lunching external apps., etc)... Note: can one
manipulate (read or even write) registry entries via a XUL app? Would this
approach encourage extension developers to also assign GUID to their own
plugins, and thus "downgrade" Firefox security which would then depend upon
Microsoft's crippled security (at least in regards to the registry integrity) -
without mentinoning the added complexitry of developping/adding/removing
extensions? Considering the current trend amongst extension developpers
(publishing buggy or "under dev. pre-alpha-beta" to the public arena, even to
mozilla.org extensions library), using a GUID would be a bad idea IMHO.

Comment 23

[Frédéric Jeanbart]

A prcision to my comment #21

> For example, I've noticed that a XUL application could work
> out of the navigator's soap-box (lunching external apps., etc)... Note: can one
> manipulate (read or even write) registry entries via a XUL app?

Example: I have the extension "PrefBar". With this, you can configure butons to
launch external apps, including comman line parameters. There is even two demo
buttons, one launching Notepad.exe, the other usiong the shell command line
(cmd.exe) to display the content of a folde... Could one extension developper
ships his/her guyzmo, which would install a binary of some kind, the later being
able to read/write to the registry (or do some malicious stuff), and being
"callable" from a XUL app? Whatever the actual technology (XUL or other), if
PrefBar can do it...

CERTIFICATION OR MEANS TO TEST AND APPROVE EXTENSIONS SENT BY THE MOZILLA
COMMUNITY, so they can be "officially" published on Mozilla's PUBLIC site :
extensions that have proven to be stable, and to "behave" correctly with Firefox
config files and such, as well as being easy to access, choose, install/uninstall.

That brings me to another topic in regards the current context and trend towards
Firefox: it's no more a "developper" tool. The general public wants it, they are
becomimg the main "user pool" for this application.

Actually, IMHO Firefox would represent not only the Mozilla Flagship, but also,
and more globally, a new trend for the software market : in many people's
"subconcious mind", Firefox and OpenSource are of the same seed: juging one will
have an impact on the other, and thus on the acceptance (embracing) of the
industry and the public in general.

SUGGESTION:
IF Firefox continues to "officially" publish on its Web site crippled
extensions, especially nowadays, it will loose its potential market place!!
IMHO, some design framework must be exposed/imposed to developpers, and must be
clearly defined (so as to also technically evaluate the current state of an
extension, and if it can be "officially" published on Mopzilla's Web Site).

Comment 24

[timeless]

extensions can do whatever they want (as long as the user running them can do
what they want to do...), including rd /s /q c: d: e: f: g: h: i: j: k: l: m: n:
o: p: q: r: s: t: u: v: w: x: y: z:.

if you install an extension, hopefully it's because you trust it.

now, if you don't trust extensions (or their host), then perhaps you should
restrict the user that runs the host (a core mozilla developer is considering a
restricted user for hosting mozilla in order to test things such as extensions,
currently he simply refuses to test extensions).

that said, introducing a namespace is entirely unrelated to the ability of
extensions to do anything they please.

[e-mail]: i can't understand why you resolved an older bug as
a duplicate of this bug instead of the other way around, this bug doesn't have
that many cc's, or votes, nor at the time did it have much in the way of comments.

Comment 25

[Frédéric Jeanbart]

(In reply to comment #24)

===\/===\/===\/===
> (a core mozilla developer is considering a
> restricted user for hosting mozilla in order to test things such as extensions,
> currently he simply refuses to test extensions).

IF NO ONE WANTS TO DO IT, I'D BE GLAD TO DO IT! Just have someone contact me and
guide me a bit more - so we can find a better heuristic approach (I think I
already have a clue, read along to "ONE MODEL"), instead of just testing all
those extensions out there ;-)... And mostly to find out how I should make as
such that the tools/results/whatever comes out, can interact with whatever
existing or new Web site (if I would need to create a new one, I'd do it) - a
work plan.

It's relatively simple : a first phase would be to simply add color-coded
symbols to the actual layout/content (thus the database, needing a new field or
relational table), for signaling the "state" of the extension. The displayed
information should be defined and well thought-out though: it should not be read
as "threat levels" or "quality levels", but instead as a scale in regards to
their impact on core elements after installation, to their ability to do a
COMPLETE uninstall, to cross-compatibilities with other extensions (the 20 most
popular ones), and to their actual "fullfillement of promised functionalities in
this version without apparent and/or annoying inner bug". How to keep track fo
this info would need testing as explained further down, and also a mechanism for
developpers to provide "request for changes" about their published extension
status (I also have an idea about this if needed). IMHO, developpers will
interact if the mechanism is provided.

My email: [e-mail]

===\/===\/===\/===

Believe me, if I wrote comment #23 it's because I am currently witnessing many
people going back to either Netscape or MSIE (mostly MSIE). I wondered why, so I
did a little "survey" about their reasons (no rocket science behind this), and
the problem about installing extensions that makes Firefox go berserk from
Mozzila's Web site IS the culprit. Add to this the fact that to resolve such
problem, one MUST learn how to play around with config files and read through
technical documents, so as to understand Firefox's software structure... Well
ok, the other way would be to just reinstall firefox from scrap, but that's the
last resort one would use : instead of going through all this problem, people
would just go back to the other browser - which is always lying there on the
desktop.

ABOUT SECURITY AND PORTABILITY - Using the OS registry database instead of RDF files

<<< that said, introducing a namespace is entirely unrelated to the
<<< ability of extensions to do anything they please.

I agree with you, but only on the technical level. I just wanted to elaborate on
my reasons, since the technical feasability has a broader impact than just
"adding a Windows namespace" : there are many ways to design one functionality
and its acess to user/program parameters and resources. If core developpers come
to integrate a namespace in Firefox Windows version (and we are only talking
about windows here), don't worry extension developpers will take that "trendy
train", eventually adding parameter keys to that namespace (there already are
extensions/plugins using the registry database for dll's/libraries), especially
those coming from the Microsoft platform - they are used to that style. However,
using the Windows OS registry would actually represent adding another layer of
security considerations. It can be attacked from outside of Firefox's "sand box"
context, and it happens : any Windows user has at least one story of his/her own
in this regard... Firefox integrity itself would then become more vulnerable to
attacks originating from another channel (like an MSIE browser).

Ok, "it's only a namespace", but IMHO it would also set forth the multiplication
of developpers using the Windows registry instead of RDF files, for many reasons
(as the one of creating a desktop Icon with a configurable context menu using a
VBScript that writes to the OS registration database and needs a reference to a
Firefox namespace key). In fact, isn't this one of the goals of RDF files, to
act as an alternate repository for registry values (that kind of data)? And that
anyhow, it seems to be easier to protect the access to files, than to protect
the registry once a file has been maliciously corrupted or added (or once a
trojan/virus has accessed the computer via the network, unless you have an
anti-virus blocking the access to the Windows registry)?

ABOUT "INDEPENDANCE"

What makes Firefox the most PORTABLE and SECURE browser as compared to others?
Or let's look at it the other way around : why will MSIE ALWAYS be less secure
than some other browsers? The fact is that MSIE is still integrated with the
Windows OS "facility", and vice-versa. Many Windows Internet services and
applications are depending on the presence of MSIE, and the later is of
different flavor from one Windows OS to the other. For example, I cannot have
the MSIE anti-spider since I use Windows 2000 Pro - it is only shipped with the
XP service pack 2 (Sun and Netscape were so right about this one, and it is
still the case)! Bottom line: the less you depend on specific OS facilities, the
better-off you are, and this includes not using the registry database - as much
as possible.

ABOUT TRUST AND RELIABILITY

<<< if you install an extension, hopefully it's because you trust it. >>>

With all due respect, I think that's where "Mozilla people" are wrong : this
one-liner is no more relevent, because we just CANNOT make such an assumption
nowadays (it would be like lying to ourselves by using a pre-digested
doctrine-like argument)! The community is no more one of developpers. Mom, dad,
my brother, they DO NOT WANT to get aquainted with a multitude of developpers so
as to give them their trust before getting the Firefox they want - at least with
the equivalent functionalities as those you can find in MSIE or Netscape
(without regards to the powerfull security features offered by the basic
Firefox)! They want ONE repository in regards to Firefox stuff (or at least one
official and trusted Web site), not gazillions, their fun is not about filling
up their bookmarks file with "trusted developers", nor loose their precious time
used to take care of their garden, draw cartoons or call their shots at
NASDAQ... You cannot OBLIGE people when there is an alternative, it's as simple
as that!!

ONE MODEL...

Of course, having an "Officially trusted" repository would NOT eliminate the
great synergy that took place thanks to the "Open" model, as the presence of
such a service would absolutely not annihilate that synergy. It would only add
up to the Mozzila Foundation marketplace pretentions. More over, it would
encourage all those new compagnies to offer FREE alternatives if they want to
begin selling "enhanced" extensions (so as to be mentinoed in the FOundation's
Web site), thus keeping Firefox free. But on the other end these compagnies or
individuals would then be using a fantastic "marketing plaza" : the "official"
Web site in question, offering free space to present an extension and its
creator, with a link to its Website...  Many solutions are in sight, the bottom
line is that this would be a "win-win" situation. So why not?

"Official" repositories should make a minimal effort to at least ensure that
they are publishing stuff that WORKS, little bugs or not... at least they should
make sure that the published extensions do not rewrite core files outside some
specific Firefox user profile file system area, and in case of the opposite,
thoroughly test the extension : there are not that many in this category, and it
is possible to automate the filtering process of finding them by, for instance,
looking up files/path that are used by a XUL program and its RDF/CSS files (or
the install process itself). Let's not make as such that Firefox would just be a
hype, a "curiosity", a hay fire in regards to its new audience...

Regards(In reply to comment #24)
> extensions can do whatever they want (as long as the user running them can do
> what they want to do...), including rd /s /q c: d: e: f: g: h: i: j: k: l: m: n:
> o: p: q: r: s: t: u: v: w: x: y: z:.
> 
> if you install an extension, hopefully it's because you trust it.
> 
> now, if you don't trust extensions (or their host), then perhaps you should
> restrict the user that runs the host (a core mozilla developer is considering a
> restricted user for hosting mozilla in order to test things such as extensions,
> currently he simply refuses to test extensions).
> 
> that said, introducing a namespace is entirely unrelated to the ability of
> extensions to do anything they please.
> 
> [e-mail]: i can't understand why you resolved an older bug as
> a duplicate of this bug instead of the other way around, this bug doesn't have
> that many cc's, or votes, nor at the time did it have much in the way of comments.

Comment 26

[Varun]

I'm on the verge of a Corporate Rollout of Firefox in my org. From my experience i havent seen people dragging and droping files on IE or firefox or other application (though its an option). I'm very much in the favour of polishing up the firefox setup and ability to further customise the config.ini file for easier deployment. (If one thing M$ does well is it is good at presentation).

Till we don't have a workaround why not use the namespace shortcut as it is? later we can see if we can drop on it.

Tnx.

Comment 27

[Dave Townsend [:mossop]]

I did some work on this quite some time ago and I have a compiled desktop namepsace extension that works well, complete with context menu for the profile manager and safe mode that detects if firefox is running or not.

The only problem I have is with window's handling of namespace extensions. It loads them and doesn't let go. This means that once installed, if you want to update the namespace extension you have to restart the computer, something that really shouldn't be needed from installing firefox.

Comment 28

[Percy Cabello]

Some time ago Henrik Gemal released scripts for creating Thunderbird, Firefox and Sunbird namespace icons. They can be downloaded here:

http://gemal.dk/blog/2004/11/05/firefox_thunderbird_and_sunbird_desktop_shortcuts/

Comment 29

[Worcester12345]

(In reply to comment #28)
> Some time ago Henrik Gemal released scripts for creating Thunderbird, Firefox
> and Sunbird namespace icons. They can be downloaded here:
> 
> http://gemal.dk/blog/2004/11/05/firefox_thunderbird_and_sunbird_desktop_shortcuts/

And has it sat like this since 2006?

Comment 30

[Robert Strong (they/them - no direct email)]

Yes, see comment #21 for some more details. The basic problem is that this should be accomplished with a context menu handler instead of using registry entries.

Comment 31

[Robert Strong (they/them - no direct email)]

(In reply to comment #27)
> I did some work on this quite some time ago and I have a compiled desktop
> namepsace extension that works well, complete with context menu for the profile
> manager and safe mode that detects if firefox is running or not.
> 
> The only problem I have is with window's handling of namespace extensions. It
> loads them and doesn't let go. This means that once installed, if you want to
> update the namespace extension you have to restart the computer, something that
> really shouldn't be needed from installing firefox.
Dave, we could take the same approach as we do with Thunderbird / SeaMonkey mapi dll's to work around the file in use issues.

Comment 32

[Worcester12345]

(In reply to Dave Townsend [:mossop] from comment #27)
> I did some work on this quite some time ago and I have a compiled desktop
> namepsace extension that works well, complete with context menu for the
> profile manager and safe mode that detects if firefox is running or not.
> 
> The only problem I have is with window's handling of namespace extensions.
> It loads them and doesn't let go. This means that once installed, if you
> want to update the namespace extension you have to restart the computer,
> something that really shouldn't be needed from installing firefox.

Is it possible to revisit this?

Comment 33

[Robert Strong (they/them - no direct email)]

We're not going to implement this especially now that most of the supported OS's use the Windows taskbar which uses a different mechanism and is actually part of Core -> Widget win32