268494 - "Set as default browser" should preserve context menu options for files in explorer (shell commands)

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, enhancement)

Description

[Uri]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.7.3) Gecko/20040910

This problem exists in Firefox 0.10 with Mozilla 1.7.3. It did not exists in the
previous version of Firefox that I used (I think it was 0.09 with Mizilla 1.6.8.)

Since Firefox does not contain a composer, when you set Firefax as the default
browser it does not list Edit (to edit HTMP pages) as a menu item in Windows
Explorer's. So I created one and set Mozilla in composer mode as the application
for this menu item. I also created "Edit with Netscape" as another menu item
with the corresponding Netscape's composer as the application.

Some time later I changed the default browser to Mozilla. The two editing menu
items were present and usable following this change.

When I reset Firefox as the default browser both menu items for editing HTML
pages were removed.


Reproducible: Always
Steps to Reproduce:
1. Set the default browser to Mozilla or Netscape.

2. Create Edit action for the HTM, HTML file extensions In Windows' Explorer.

   2.1. Verify that when Right- clicking on HTML file the new action you created
such as "Edit" or "Edit with Mozilla" or "EDit with netscape" are present and
functional.

3. Set the default browser to Firefox.

   3.1. Verify that the editing actions on right click are gone.

Actual Results:  
The editing actions on right click are gone from Windows Explorer's right-click
menu.

Expected Results:  
The menu items should remain visible, active and functional.

Comment 2

[:Paolo Amadini]

This is a Windows 95 bug. If this still applies today, feel free to reopen.

Comment 3

[Alex Andrews]

(In reply to Paolo Amadini [:paolo] from comment #2)
> This is a Windows 95 bug. If this still applies today, feel free to reopen.

I am using FF 20.0.1 and this appears to have been fixed.  Not quite sure why "Paolo Amadini" didn't bother to check whether or not this problem had actually been fixed before marking it as "INVALID" - was it incompetence or just sheer laziness?  I am erring on the side of incompetence seeing as he thought it was just a Windows 95 issue when the bug report clearly states it is a problem right up to Windows XP...

Comment 4

[:Paolo Amadini]

(In reply to Alex Andrews from comment #3)
> I am using FF 20.0.1 and this appears to have been fixed.

Thank you for verifying that this has been fixed, this is a helpful contribution.

I've updated the resolution to WORKSFORME, because INVALID means that the bug
may no longer apply to the latest version (not that the report was invalid -
this was a good report when it was written). When assessing the applicability,
I looked at the original report but missed the duplicate bug 339044.

While we do sometimes ask bug reporters to verify old bugs that may no longer
apply, I apologize for the terseness of the original messaging - I was going
through several old bugs at once and I agree I could have spent some more
time on this particular one.