From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204 BuildID: 2002020406 After installing Mozilla for Windows 2000, I noticed that the Windows popup context menu for HTML files had been tampered with. Specifically, the 'Edit with Dreamweaver' option had been removed. Yes - Composer is quite a decent WYSIWYG HTML editor, but it lacks a few of Dreamweaver's features, particularly the ability to edit a frameset and its constituent frames visually. I think that removing the Dreamweaver context menu popup is not a justifiable behaviour on the part of the Mozilla installer, particularly since it doesn't ask the user's consent, or even make them available that this is what's happening. Reproducible: Always Steps to Reproduce: 1. Install Macromedia Dreamweaver 2. Right-click on an HTML file, and note the presence of 'Edit with Dreamweaver' on the context menu 3. Install Mozilla 4. Right-click on an HTML file, and note that the 'Edit with Dreamweaver' option has been removed :( Actual Results: as described in 'steps to reproduce' Expected Results: It should have preserved the existing context menu actions, but added an additional action of 'Edit with Mozilla Composer'.
-> XP APPS
Assignee: dveditz → trudelle
Component: Installer → XP Apps
QA Contact: bugzilla → sairuh
Assignee: trudelle → law
Isn't this related to file type association?
Capturing file ass. and adding context-menu items are two different things.
Hm, Wfm Release 1.2b Reporter: Does this problem still occour with a current build?
Dear Reporter -- Please tell us whether or not the bug still happens on a current build. Otherwise, the bug will probably get marked INVALID in a few days (Probably November 10). (No offense -- Bugzilla doesn't have any "this bug was really well written but we can't reproduce it now" option.) -M
err. this is simple to describe to anyone. if anyone wants an explanation of what happened they can ask me about it on irc. >assoc .htm .htm=htmlfile that should be ie's version n4's is called 'netscapemarkup' iirc mozilla's is probably mozillafile. there's no provision for context menus to be moved from one owner's flavor to another, and doing it would break things. .htm=timelessFile imagine timelessFile has open, print, printto, edit, and sendto verbs now imagine that mozilla has no print verb (actually you don't need to imagine this...) and that timelessFile's print verb uses timeless.exe to do a really crumy (use your imagination -- i am willing to supply an app which implements this if you care) job of printing html pages. suppose you install mozilla and tell it you want it to be your default browser. mozilla changes .htm to mozillafile and copies any verbs it doesn't have. this includes print. now imagine we actually fix mozilla so that it provides an icon for files it owns, so you see: [cutemozilla html file icon] html401strict-acidtest.html (mozilla html file) you select file>print from explorer (my computer), and then complain about the really crumy job of printing it mozilla did. some poor soul tries to figure out how this happened. if they're really lucky or if you were really clear about what you did and they happen to know a lot about what mozilla doesn't support they /might/ figure out that it wasn't mozilla that did the printing. trudelle: do we want to solve this? reporter: the fix is for you to tell dreamweaver to reassociate itself with stuff. if it can't, then that's a bug in dreamweaver. this is partially an os bug (explorer in windows2000 will ignore any shell verbs listed under an extension if the extension is mapped to a type). but mostly this is just part of the way explorer was designed, it's not necessarily wrong, there's really no way anyone can win. bad things will happen. i suppose it's really a bug in dreamweaver, it abused the os trust (the shell key is for use by the program, not third party programs) and broke when something perfectly legal happened.
Summary: Context menu violation → mozilla replaces file associations with its own set
So, is this WONTFIX? -M
15 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.