88287 - Unable to remove user specified helper apps

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Scott MacGregor]

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.

Comment 1

[Scott MacGregor]

adding some keyword mumbo jumbo....

Comment 2

[sairuh (rarely reading bugmail)]

hmmm, could this be a variation or dup of bug 84395?

Comment 3

[Paul Chen]

nav triage team:

mark nsbeta1+ and reassigning to Blake

Comment 4

[Blake Ross]

Hmm...I can't reproduce this...

Comment 5

[Scott MacGregor]

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

[Blake Ross]

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?

Comment 7

[Scott MacGregor]

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

[Blake Ross]

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?

Comment 9

[Scott MacGregor]

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.

Comment 10

[sairuh (rarely reading bugmail)]

*** Bug 84395 has been marked as a duplicate of this bug. ***

Comment 11

[sairuh (rarely reading bugmail)]

marking all since i saw this on mac in bug 84395.

Comment 12

[Blake Ross]

Attachment: my mimeTypes.rdf

Comment 13

[Scott MacGregor]

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.

Comment 14

[sairuh (rarely reading bugmail)]

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

[Blake Ross]

I notice that if I delete, restart, delete again, and restart, it seems to be 
gone for good.

Comment 16

[sairuh (rarely reading bugmail)]

yep, that's the trick i used in the other bug.

Comment 17

[Blake Ross]

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).

Comment 18

[sairuh (rarely reading bugmail)]

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.

Comment 19

[sairuh (rarely reading bugmail)]

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. ;)

Comment 20

[Viswanath Ramachandran]

removing nsBranch - not a Netscape 6.1 stopper. 

Comment 21

[sairuh (rarely reading bugmail)]

cc'ing jatin so that the workaround for this can go into the relnotes.

Comment 22

[Jatin Billimoria]

Please add this bug with workaround in bug 90577.

Comment 23

[Viswanath Ramachandran]

adding Bill Law to help Blake with this bug. 

Comment 24

[Blake Ross]

--> law

Comment 25

[sairuh (rarely reading bugmail)]

nominating...dunno if there'll be time.

Comment 26

[grega]

doesn't look like a stop ship.  Marking nsbranch-, let me know if you think
otherwise.

Comment 27

[Bill Law]

Adding Samir to cc: list (he has a similar kind of bug).  Setting target 
milestone.

Comment 28

[Bill Law]

->mozillza0.9.7

Comment 29

[Bill Law]

Attachment: 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

[Samir Gehani]

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?

Comment 31

[Bill Law]

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).

Comment 32

[Scott MacGregor]

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. 

Comment 33

[sairuh (rarely reading bugmail)]

when this is checked in, we should see if bug 93173 and bug 48948 somehow get
fixed along the way... :)

Comment 34

[Chris Waterson]

Comment on attachment 59638 [details] [diff] [review]
fix

sr=waterson

Comment 35

[Bill Law]

fixed

Comment 36

[Dawn Endico]

removing relnote item for this fixed bug

Comment 37

[sairuh (rarely reading bugmail)]

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.

Comment 38

[sairuh (rarely reading bugmail)]

drat, bug 93173 is still an issue. will post current observations there.