Windows integration prevents use of other associations

RESOLVED WORKSFORME

Status

SeaMonkey
UI Design
RESOLVED WORKSFORME
16 years ago
12 years ago

People

(Reporter: Konrad, Assigned: jag (Peter Annema))

Tracking

({helpwanted, qawanted})

Trunk
x86
Windows 95
helpwanted, qawanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: win32-registry)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.3) Gecko/20010801
BuildID:    20010801

Windows integration: If you choose Mozilla should be standard application for
htm(l)-files, it does change the registry value for .htm and .html from htmlfile
to MozillaHTML.
This way all other associations with html-files aren´t available anymore !
Mozilla should either change commands only or copy the other associations.
BTW No association for printing, neither in W95b nor in W2k.


Reproducible: Always
Steps to Reproduce:
1. Make IE or Netscape 4 your default browser
2. Make an association, i.E. Edit with Notepad
3. Make Mozilla your default browser
4. You cannot use "Edit with Notepad" anymore

Actual Results:  Association isn´t visible anymore

Expected Results:  I can still use other programs to access html files.

Comment 1

16 years ago
->xpapps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Paul Chen: Isn't it this way by design? WONTFIX?
win32 int->law.
Assignee: pchen → law

Comment 4

16 years ago
This whole area sucks.  Communicator always changed .html/.htm to
"MozillaMarkup" or some such.  I don't know exactly why that was.

There are problems no matter which way you go.  Say IE is your browser and IE
displays some funky file extensions (like the funny pseudo-html that it writes
if you "customize" a folder; I think those are .htt or .hta, or some such).  If
those files are mapped to htmlfile, then clicking on them works.  If we change
htmlfile to use Mozilla, then Mozilla will be called to display those funky
extensions, also.

There might also be complications doing the "undo" operation when the user
uninstalls Mozilla (or changes the prefs).

Anyway, this whole area is subject to change as I tackle all the "os
integration" bugs for mozilla0.9.7.  I'll add this to the list.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.7

Comment 5

16 years ago
Resetting target milestone for all "window integration" bugs to mozilla0.9.8.  
I'm working on performance and won't get to that till next milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 6

16 years ago
Not getting to this, either.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: qawanted

Updated

16 years ago
Whiteboard: win32-registry

Updated

16 years ago
Depends on: 59078
Target Milestone: mozilla0.9.9 → ---

Updated

16 years ago
Target Milestone: --- → mozilla1.0

Comment 7

16 years ago
See my comment from today in bug 59078.  I think we should toast all of the
"MozillaXXXX" entries that we make for integration.

Comment 8

16 years ago
Spam: Moving out bugs that there is no time for.

Please note that some of these will hopefully be fixed in the course of fixing 
bug 59078.  I just can't commit to fixing them all.
Keywords: helpwanted
Target Milestone: mozilla1.0 → Future

Comment 9

16 years ago
Changing qa contact to me, as I am working on these now ;-)
QA Contact: sairuh → tpreston

Comment 10

15 years ago
qa contact windows integration-> pmac
QA Contact: tpreston → pmac
Product: Core → Mozilla Application Suite

Comment 11

13 years ago
Is this still a problem?
Assignee: law → jag
Status: ASSIGNED → NEW
QA Contact: pmac
Target Milestone: Future → ---

Comment 12

12 years ago
resolving WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.