Unable to remove user specified helper apps

VERIFIED FIXED in mozilla0.9.7

Status

P2
major
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: mscott, Assigned: law)

Tracking

({relnote})

Trunk
mozilla0.9.7
relnote

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
adding some keyword mumbo jumbo....
Severity: normal → major
Keywords: nsbeta1, nsBranch
hmmm, could this be a variation or dup of bug 84395?

Comment 3

18 years ago
nav triage team:

mark nsbeta1+ and reassigning to Blake
Assignee: pchen → blaker
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3

Comment 4

18 years ago
Hmm...I can't reproduce this...
(Reporter)

Comment 5

18 years ago
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. 

Comment 6

18 years ago
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?
(Reporter)

Comment 7

18 years ago
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. 

Comment 8

18 years ago
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
(Reporter)

Comment 9

18 years ago
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

Comment 12

18 years ago
Created attachment 40709 [details]
my mimeTypes.rdf
(Reporter)

Comment 13

18 years ago
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?

Comment 15

18 years ago
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.

Comment 17

18 years ago
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. 
Keywords: nsBranch
cc'ing jatin so that the workaround for this can go into the relnotes.
Keywords: relnote

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 22

18 years ago
Please add this bug with workaround in bug 90577.
adding Bill Law to help Blake with this bug. 

Comment 24

17 years ago
--> law
Assignee: blaker → law
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.4 → ---
nominating...dunno if there'll be time.
Keywords: mozilla0.9.4, nsbranch

Comment 26

17 years ago
doesn't look like a stop ship.  Marking nsbranch-, let me know if you think
otherwise.
Keywords: nsbranch → nsbranch-

Updated

17 years ago
Blocks: 99227

Updated

17 years ago
No longer blocks: 99227
(Assignee)

Comment 27

17 years ago
Adding Samir to cc: list (he has a similar kind of bug).  Setting target 
milestone.
Target Milestone: --- → mozilla0.9.6

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-
(Assignee)

Comment 28

17 years ago
->mozillza0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Comment 29

17 years ago
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 30

17 years ago
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+
(Assignee)

Comment 31

17 years ago
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).
(Reporter)

Comment 32

17 years ago
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. 
when this is checked in, we should see if bug 93173 and bug 48948 somehow get
fixed along the way... :)
(Assignee)

Updated

17 years ago
Whiteboard: needs a= from waterson

Updated

17 years ago
Attachment #59638 - Flags: superreview+

Comment 34

17 years ago
Comment on attachment 59638 [details] [diff] [review]
fix

sr=waterson
(Assignee)

Updated

17 years ago
Whiteboard: needs a= from waterson
(Assignee)

Comment 35

17 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 36

17 years ago
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.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.