186449 - Mozillas as Default does too much even for .html files

Status: RESOLVED EXPIRED

(SeaMonkey :: Preferences, enhancement)

Description

[River~~]

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

Comment 1

[R.K.Aa.]

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

Comment 2

[River~~]

Duplicated - network failure during commit

*** This bug has been marked as a duplicate of 186450 ***

Comment 3

[R.K.Aa.]

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.

Comment 4

[Mike Cowperthwaite]

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.

Comment 5

[timeless]

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.

Comment 6

[Gervase Markham [:gerv]]

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/

Comment 7

[Gervase Markham [:gerv]]

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.