Closed Bug 53870 Opened 24 years ago Closed 24 years ago

existing profile: cannot dismiss Edit Type dialog after changing radiobutton (Helper App panel in prefs)

Categories

(SeaMonkey :: UI Design, defect, P3)

All
Linux
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: matt)

Details

my apologies if this is a dup (shrir said it's likely a known problem), but i couldn't find this after several bugzilla queries... 0. this assume you have at least one existing mimetype listed in the Helper Applications preference panel. 1. open the Prefs dialog, select the Helper Applications category. 2. select one of the mimetypes listed under File Types, then click the Edit button. 3. change any of the radiobuttons or textfields. 4. click OK to save and dismiss the Edit Type dialog. result: the dialog will not be dismissed. using 2000.09.22.08 opt comm bits on linux, get the following console error: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFDataSource.Change]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://communicator/content/pref/overrideHandler.js :: changeMIMEStuff :: line 338" data: no]
pls reassign/dup as needed... i'd say this is a pretty necessary feature to have.
Keywords: correctness, nsbeta3
QA Contact: sairuh → shrir
I don't see this problem, actually.It works fine for me. Sairuh, I don't recall talking to you about this. It would be great if you could show me this problem. MArking WFM for the moment.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Oh..I remember now. We did talk about not being able to change the file extension once it is entered for a helper app .But I don't think that is what you mean in this bug. There is definitely a bug filed for the thing I just mentioned(cannot change file extension once entered) but is has been resolved. Pls reopen if you are seeing this.
i tried to repro this using a clean install (ie, mv'ing the .mozilla/ dir), and with a new profile i no longer see this. (used 2000.09.25.08 linux opt comm bits.) however...i did see this after 1. installing 2000.09.25.08 mozilla (still on linux), and using the same profile i had created earlier with the comm bits. 2. added a new mimetype, save/dismissed prefs. 3. reopen prefs, edit the new mimetype. 4. click the OK button in the edit type dialog... result: the dialog won't go away, unless i click Cancel. get the same js error. reopening. feel free to come over and i'll show you this. or mebbe the root of the problem is using an existing profile? (even tho' i had but recently created it...)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
assigning to matt, namely to see if this is a symptom (and thus dup) of bug 50914. also clarified summary for the particular problem i'm seeing, as well as more specific steps (long-winded, but might help clarify the issue). 0. create a new profile and launch it. 1. go to the Helper Apps panel in the Prefs dialog. 2. create a new mimetype (click the New Type button to bring up New Type dialog). for example: Description: Foo File extension: foo Mimetype: application/foo Application to use: [blank] 3. click OK. new type should appear in the File types list. 4. select the new type and click Edit... make a note that the "Application" radiobutton (under the Handled By section) is selected. 5. dismiss the Edit Type dialog by clicking OK. it should go away. 6. dismiss the Prefs dialog. 7. quit and restart the browser using that profile. 8. bring up Prefs and select the Helper Apps panel. 9. select the application/foo type in the list and click the Edit button. 10. in the Edit Type dialog, change the radiobutton to either "Navigator" or "Save to disk". 11. click the OK button. the Edit Type dialog will persist and the js error mentioned earlier will be thrown. 12. click the Cancel button. the Edit Type dialog is dismissed. 13. bring up the Edit Type dialog *again* for application/foo. observe: the change made in steps 10-11 *is actually saved*, it's just for some reason the OK no longer *dismisses* the dialog. (although Cancel does dismiss it.)
Assignee: mscott → matt
Severity: critical → normal
Status: REOPENED → NEW
Summary: cannot edit existing mimetypes (Helper App panel in prefs) → cannot dismiss Edit Type dialog after changing radiobutton (Helper App panel in prefs)
further summary clarification.
Summary: cannot dismiss Edit Type dialog after changing radiobutton (Helper App panel in prefs) → existing profile: cannot dismiss Edit Type dialog after changing radiobutton (Helper App panel in prefs)
Minus for beta 3. Does anyone want to nominate this for RTM.
Whiteboard: [nsbeta3-]
out of curiousity sarah, does the workaround for bug 50914 work here? that might answer your dupe question.
tried the workaround for bug 50914, ie, removing the mimeTypes.rdf (if it exists --it doesn't for migrated profiles). it did not work. so, this i believe is a separate bug. unless the workaround for bug 50914 isn't reliable...
I had a problem when installing build 2000092013/Linux at home. I got the simptoms from bug 50914 and noticed that I didn't have a mimeTypes.rdf file. I did, however, find a mimeTypes.rdf file in my ~/.mozilla/default/en-US directory. Moving this file down into my ~/.mozilla/default directory fixed the problem.
i tried another workaround which didn't work: 0. made sure that there are no instances of netscape6 running. (btw, am using 2000.09.29.09-n6, optimized commercial branch bits.) 1. copied mimeTypes.rdf from [install_dir]/defaults/profile/ 2. started netscape6 (using an existing non-migrated profile, to keep this seperate from bug 50914). 3. follow steps 1-13 above from my [2000-09-25 14:21] entry. results: still cannot dismiss the Edit Type dialog after hitting the OK button. still need to hit OK then Cancel to dismiss it. so, the workaround for bug 50914 doesn't work here, alas... (at least the current workaround here is okay, tho' not great.)
I can't repro this. Any update, sairuh ?
alas, this is still happening [following steps in my 2000-09-25 14:21 comments], using 2000.11.21.08 trunk bits [on linux, at least].
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Given that flaky and broken helper app controls were one of the most prominent complaints of 6.0, beta1 really shouldn't ship with this.
Keywords: nsbeta1
Um, what about the fact that editing a helper app doesn't actually do anything? Is there a bug on that? On the latest nightly (and NS6), if you edit a helper and change the type or app, it doesn't get saved. Weirder than that, if you create a new type that has the type of what you tried to change the other type to, it says it already exists. Example: create type abcdefg Edit it to abc Save - note it doesn't change Create a new type abc - error says it already exists even though it doesn't
yes the problems mentioned do have bugs, however there doesn't appear to be anyone working on them.
Eric: What are your thoughts on the priority of the many helper app bugs?
nav triage team: This W4M using mac build from today, 01/26/01. Other helper apps bugs are logged for all the other issues
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
this is again a dup of the original helper app issue (mimetypes.rdf format change). VERIFIED.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.