Closed Bug 186449 Opened 21 years ago Closed 18 years ago
Mozillas as Default does too much even for .html files
(SeaMonkey :: Preferences, enhancement)
(Reporter: river, Assigned: neil)
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021216 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021216 NB - different from bug 131106 When Mozilla is set as default it does too much. Part of the problem is well described in 131106 and is not repeated here. The additional problem is that even when it is appropriate for Mozilla to change the entries for a particular file type, it does too much to that filetype. In my view it should replace the right-click options Open and Edit, and possibly Print, but leave the others intact. At present it deletes the other options. So for example if you have set up a right click option "Open with MyEdit" Mozilla should copy the definition into the new one. I suggest this new behaviour should apply to each file type separately that is being adjusted. Which file types these will be will depend on bug 131106, but will always include .html and .htm Reproducible: Always Steps to Reproduce: 1. Set up a custom right-click option for .html files (Open with MyEdit, say) on a MS-Win machine 2. Right click on .html file to see option Open with MyEdit 3. Set Mozilla as default browser 4. Right click on .html file and you won't see Open with MyEdit Actual Results: see 4 in Steps to reproduce Expected Results: Copied the old right click entries for that filetype for all right click options it was not going to change
*** Bug 186450 has been marked as a duplicate of this bug. ***
Duplicated - network failure during commit *** This bug has been marked as a duplicate of 186450 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Bugzilla shouldn't have allowed this. And please dup to older bug unless there are reasons to do it the other way around. Reopening. I believe this bug is plain invalid, however.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
19 years ago
I don't believe there is a viable solution from within Mozilla. The context menu items from the previous selection are not actually deleted; they are stored in one particular location in the registry, and not copied to the new location when Mozilla installs itself: Given a Windows system with the default (IE) assocations, the registry keys under HKEY_CLASSES_ROOT (HKCR for short) are set up as follows: HKCR\.htm -> "htmlfile" HKCR\.html -> "htmlfile" HKCR\htmlfile -> "HTML Document" shell (subkey) open, opennew, print, printto (sub-subkeys) After installing Mozilla, the first two keys' values are changed to "MozillaHTML" and these keys are added: HKCR\MozillaHTML -> "HTML Document" shell open, print These 'open' and 'print' keys are the commands supplied by Mozilla. It is not examining any of the commands in the 'htmlfile' key, it merely sets up its own. Rather than "doing too much," reporter's real complaint is that Mozilla is not doing enough. Unfortunately, there is no good way for Mozilla to be able to determine whether any given subkey from the previously configured key should or should not be copied. For instance, what if the user had defined "Open with Mozilla" as one of the commands? That would make no sense for Mozilla to copy over. I don't know that the bug is invalid -- it would be possible to do *something* here -- but the amount of code and UI required to achieve it sensibly would be far more than the problem's importance demands. Recommend WontFix. Incidentally, integration to system file associations is not a Preferences issue; this bug probably should be in the XP Apps component.
personally i'm considering copying over any verb which uses an application which isn't the one owned by "open" or @default. i had a more detailed ruleset somewhere, but i doubt i'll find it befor i find someone to work on it.
Assignee: bugs → neil.parkwaycc.co.uk
19 years ago
Product: Browser → Seamonkey
18 years ago
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
18 years ago
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.