88429 - cancelling overwrite of helper app pref still overwrites setting

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[sairuh (rarely reading bugmail)]

found using 2001.06.29.06-trunk comm bits on win98. not sure if this is 
already known. pls reassign as needed...

summary: if i already have a helper app [defined in the pref panel] for 
application/foo, then create another one with same mime --but with different 
description, extension, *or* application-- i'm prompted as to whether i want to 
overwrite the existing one. if i hit Cancel, however, the existing one is 
overwritten anyhow.

recipe:
1. in the helper applications preferences panel, create a helper app with the 
following settings [click "New Type"]:
  description: Foo files
  extension: foo
  mimetype: application/foo
  handled by: winzip.exe [selected path to .exe on my machine]
2. click OK, helper app is created just fine.
2. create another helper app with the following settings [again, click "New 
Type"]:
  description: Zub files
  extension: zub
  mimetype: application/foo
  handled by: [leave blank]
3. click OK, result: get a dialog sayinging "A helper alrady exists for MIME 
type 'application/foo'. Do you want to replace it?"
4. click Cancel.
5. in the pref panel, select the application/foo item in the listbox.

results:
* "Extension" now has two entries: foo zub (interesting way to get multiple 
extensions ;).
* the helper app ["Handled by"] entry is now gone.

Comment 1

[sairuh (rarely reading bugmail)]

well, implied dataloss, since a setting which was cancelled was really 
overwritten.

will check later on other platforms...

Comment 2

[Scott MacGregor]

over to xp-apps / pref's helper app panel owners...

Comment 3

[Paul Chen]

nav triage team:

marking nsbeta1+, p3, and mozilla0.9.3

Comment 4

[Viswanath Ramachandran]

nav triage -> m1.0, not a frequent enuff user action to be a stopper at this 
time. 

Comment 5

[sairuh (rarely reading bugmail)]

this might not be a frequently-used feature, but the behavior is incorrect! when
you cancel, *nothing* should be done --and in this case, something *is* done and
it changes user's setting. rather deceptive, if you ask me...

adding helpwanted...

Comment 6

[Scott MacGregor]

the following code must be failing for some reason:

  if (exists) {
    var titleMsg = gPrefApplicationsBundle.getString("handlerExistsTitle");
    var dialogMsg = gPrefApplicationsBundle.getString("handlerExists");
    dialogMsg = dialogMsg.replace(/%mime%/g, gMIMEField.value);
    var promptService =
Components.classes["@mozilla.org/embedcomp/prompt-service;1"].getService(Components.interfaces.nsIPromptService);
    var replace = promptService.confirm(window, titleMsg, dialogMsg);
    if (!replace)
      window.close();
  }

this is in pref-application-new.js

I bet we just need a return in front of that window.close. o.t. we'll keep
processing after the if clause and end up replacing the content. I'll post the fix.

Comment 7

[Scott MacGregor]

Attachment: the fix.

Comment 8

[Scott MacGregor]

we should really try to get this one line change into rtm. o.t. we introduce
data loss.

Comment 9

[Scott MacGregor]

sr=blake for this bug.

Comment 10

[Scott MacGregor]

this 0 risk fix has been checked into the trunk. 

Comment 11

[sairuh (rarely reading bugmail)]

->all, since i see this w/2001.07.03.16-trunk bits on linux.

will test once my debug finishes building.

Comment 12

[sairuh (rarely reading bugmail)]

this is fixed on my linux debug.

Comment 13

[scottputterman]

When the branch is open, please check this into it today.

Comment 14

[sairuh (rarely reading bugmail)]

vrfy'd fixed using the following comm trunk builds:

linux 2001.07.05.08
winnt 2001.07.05.09
mac 2001.07.05.08

removing vtrunk kw.

Comment 15

[Scott MacGregor]

fixed on the branch.

Comment 16

[sairuh (rarely reading bugmail)]

vrfy fixed on the branch using the following commercial branch bits:

linux - 2001.07.09.04
winnt - 2001.07.09.05
mac - 2001.07.09.03