The "Remove button" under Edit / Preferences / Navigator / Helper apps doesn't appear to really be removing the mime type from our data source. I added a couple mime types and then wanted to remove them so I could start using the system default settings for that mime type. I noticed that clicking remove, removes the mime type from the view but if I quit and restart the app, the mime type is back there in the view again. I think this is a stop ship bug because it can interfere with out ability to read out system settings from the OS when trying to lauch a helper app for the mime type.
adding some keyword mumbo jumbo....
Severity: normal → major
Keywords: nsbeta1, nsBranch
hmmm, could this be a variation or dup of bug 84395?
nav triage team: mark nsbeta1+ and reassigning to Blake
Assignee: pchen → blaker
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
Hmm...I can't reproduce this...
hmmm...all I have to do is quit and restart the app and all the mime types i deleted are back again. I don't think I did anything else besides that.
I tried adding ~4 new mimetypes ('test1', 'test2', 'test3', 'test4'). I then removed each, restarting, opened helper apps, and they weren't there. I also tried other things, like adding, restarting, removing, and restarting, but it worked every time. Are you adding them via the New Type... button, or are these ones you've added via the helper app dialog at various times?
I've added these via the helper app dialog's advanced button and from the prefs panel. Neither seem to delete. Maybe all of them were added via the advanced button from the helper app dialog. I'm not sure.
Okay, Sarah helped me break this down: when you add it via Advanced (from the helper app dialog), it won't properly get removed. If you add it from the prefs dialog, it will. That's interesting, because it's the same dialog... Looking into it now. Scott, do you have any idea offhand why such a distinction would matter?
Status: NEW → ASSIGNED
Hmm, I'm not sure why they would behave differently by adding them. You could start with a new profile. Add a mime type via the prefs panel. Then add another mime type via the helper app dialog. Now quit the app. Open up the mimeTypes.rdf file in your profile directory. You should see data for your 2 mime types. We can see if there's a difference between the two? Maybe that will help. for what it's worth, the code that brings up the new mime type dialog from the helper app dialog is in nsHelperAppDlg.js in a method called setDefault.
*** Bug 84395 has been marked as a duplicate of this bug. ***
marking all since i saw this on mac in bug 84395.
OS: Windows 2000 → All
Hardware: PC → All
I wonder if this has to do with the fact that we read in the RDF data source in 2 different places. One is in the mime service code in uriloader\exthandler and the other time is in the prefs panel when we load the data source. Actually we do it 3 times because Bill's code in nsHelperApp.js::setDefault also loads the data source. Maybe there's a problem when multiple instances are floating around. IN theory there shouldn't be since we are reflecting the same in memory data source just in multiple places.
hrm, just tested this on the Mac [2001.06.29.04-trunk mozilla]. i encounter this problem when i create the mimetype from *either* the prefs panel or the "advanced" button. was i too hasty in marking bug 84395 a dup? or, is the mac just exhibiting differing behavior due to the same root cause?
I notice that if I delete, restart, delete again, and restart, it seems to be gone for good.
yep, that's the trick i used in the other bug.
I'm just lost on this one... I played around with the code so that the dialog is launched in almost the exact same manner from each caller (the difference being that it's launched via nsIWindowWatcher from the helper all dlg, by necessity). I have no idea why this is happening. It might be scott's theory about multiple datasources, but that seems unlikely, especially since I removed all the code that loaded the datasource from setDefault (just to test).
observation: finally seeing this on linux as well [2001.07.09.04-branch commercial]. kinda like my mac experience: saw this even though there wasn't an OS-defined helper app. same workaround applies, too.
fooey, let me rephrase my last comment: like my Mac experience, i saw this problem when i created the mimetype from *either* the prefs panel or the "advanced" button. that's what i meant to say. honest. ;)
removing nsBranch - not a Netscape 6.1 stopper.
cc'ing jatin so that the workaround for this can go into the relnotes.
Please add this bug with workaround in bug 90577.
adding Bill Law to help Blake with this bug.
Assignee: blaker → law
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.4 → ---
nominating...dunno if there'll be time.
Keywords: mozilla0.9.4, nsbranch
doesn't look like a stop ship. Marking nsbranch-, let me know if you think otherwise.
Keywords: nsbranch → nsbranch-
Adding Samir to cc: list (he has a similar kind of bug). Setting target milestone.
Target Milestone: --- → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Created attachment 59638 [details] [diff] [review] fix This fix has a number of pieces: 1. It adds a new GetDataSourceBlocking method to nsIRDFService that lets you get a data source and load it synchronously (versus the asynchronous load GetDataSource does). 2. Changes to the uriloader to use that method (ensuring it gets the same data source if the pref panel had already been opened). 3. Changes to the helper app dialog to use that method (ditto). 4. Adds a Flush() call when an entry is deleted from the pref panel. 5. (extra credit) I added code to the "Edit Type" dialog to make the mime type field read-only when being opened via the helper app dialog. We were ignoring any input in that field in that situation and I thought it might be confusing to the user if we let them enter a new type but then never had that type show up in the pref panel.
Comment on attachment 59638 [details] [diff] [review] fix Cool! r=sgehani What is the impact of this patch on ``large'' mimetypes.rdf datasources? Does the blocking call happen on the UI thread or is there no perceived sluggishness?
Attachment #59638 - Flags: review+
The "ui" (prefs panel) still does a non-blocking load, so there is no impact. The "non ui" (uriloader) still does a blocking load, so there is no change there either. The difference is that the uriloader doesn't do this load if the rdf service already has the data source. The helper app dialog is a hybrid case. It issues a blocking request but in effect that never takes effect because the data source will already be loaded (because the uriloader loads it before opening the helper app dialog).
I feel comfortable sr'ing everything but the RDF changes which should get watersons review since he's the module owner. sr=mscott for the rest.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
removing relnote item for this fixed bug
sorry for the long delay. vrfy'd fixed using 2002.01.23.0x comm bits on linux rh7.2, win2k and mac os 10.1.2. tested both type create from the pref panel, as well as via the advanced button.
Status: RESOLVED → VERIFIED
drat, bug 93173 is still an issue. will post current observations there.
You need to log in before you can comment on or make changes to this bug.