Closed Bug 264889 Opened 20 years ago Closed 7 years ago

Firefox Desktop Namespace Icon

Categories

(Firefox :: Shell Integration, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ayo_adedipe, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(4 files)

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:
Severity: normal → enhancement
Is a namespace icon what IE has? If it is, I think this is a dup of bug 259830.
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.
Component: Installer → OS Integration
Yes I think this is a dupe of bug 259830
*** Bug 259830 has been marked as a duplicate of this bug. ***
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 266713 has been marked as a duplicate of this bug. ***
*** Bug 248443 has been marked as a duplicate of this bug. ***
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 #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.
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.
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" ------------------------------------------
Attached image 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?
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.
>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
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.
I have filed bug 288589 for Thunderbird's desktop icon. NOTE: I apologise for my lengthy discussion with David can it be removed?
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.
(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.
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).
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. bugzilla@babylonsounds.com: 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.
(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: f.jeanbart@gmail.com ===\/===\/===\/=== 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. > > bugzilla@babylonsounds.com: 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.
Assignee: bugs → nobody
QA Contact: bugzilla → os.integration
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.
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.
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/
(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?
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.
Blocks: 288589
(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.
(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?
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
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: