98296 - helper app defined from prefs panel won't work

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P2)

Description

[sairuh (rarely reading bugmail)]

found using 2001.09.04.11-comm bits on Mac OS 9.1. if i define a helper app from
the preferences panel for a mimetype where there's no OS-defined helper app, the
helper app dialog somehow does not pick it up.

oddly enough, this is not a problem if i define the helper app directly from the
helper app dialog via the Advanced button.

1. go to the Helper Applications panel in the prefs dialog.
2. click New Type, and fill out the resulting dialog. eg, i used the following:
  Description: Portable doc format
  extension: pdf
  mimetype: application/pdf
  application: [path to Adobe Acrobat Reader]
3. clicked OK, OK.
4. clicked on a pdf link, eg, one of the links at
http://www.mozilla.org/quality/browser/front-end/testcases/plugins/acrobattest.html
5. looking at the resulting helper app dialog.

expected: the helper app dialog should have "Open using Acrobat Reader" selected.

actual: the helper app dialog opens with "Save this file to disk" selected.
moreover, the Open option has "Open using <no application specified>".

Comment 1

[sairuh (rarely reading bugmail)]

nominating.

not a problem on winnt or linux.

Comment 2

[grega]

marking nsbranch+, pdt.  How close are we to fixing?  What does the fix involve?

Comment 3

[selmer (gone)]

->095 since we're asking for this in the current release.  Is this going to
happen in the next couple days?

Comment 4

[Samir Gehani]

Accepting.

Comment 5

[Samir Gehani]

se, can you help me by isolating between which two builds this first started
occuring?  (If sweetlou doesn't have enough nightlies ftp.mozilla.org seems to
be a good place to turn to.)  Thanks.

Comment 6

[Samir Gehani]

I cannot reproduce this with a build pulled a couple of days ago from the trunk.
 I get the expected results as listed by se in the original report.  

If I add the MIME type and click on a pdf link from the cited test page, I get
the dialog with the "Open using Acrobat Reader" radio button selected.  If I
then proceed to remove this MIME type association via the Helper Apps pref panel
and click on a pdf link, I get the the dialog with "Save this file to disk"
selected and the open option has the "Open using <no application specified>"
radio button selected.

se, is this branch-specific?  

Comment 7

[Jaime Rodriguez, Jr.]

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Comment 8

[sairuh (rarely reading bugmail)]

fooey --this is still a problem using either commercial branch
[2001.09.24.03-0.9.4] or trunk [2001.09.24.13-trunk] bits on Mac OS 9.1. :( 
reopening.

samir, perhaps it works for you because application/pdf might already be
predefined for you mac [check your Internet Config]. this bug, however, seems to
occur with any user-defined mimetype [not already defined by OS] on mac --so,
try testing with another type. eg, use the following when defining the handler
in the prefs panel:

extension: exe
mimetype: application/octet-stream
application to use: [i arbitrarily selected the path to bbedit v5.1]

sample file to click: go to ftp://ftp.mozilla.org/pub/mozilla/nightly/ and go
into a build dir that contains an .exe file, then click it.

Comment 9

[Jaime Rodriguez, Jr.]

We'd like to take all regression fixes when available. - PDT

Samir - Pls look into this one, and give us an ETA.

Comment 10

[selmer (gone)]

Samir, what's your progress on this bug?

Comment 11

[Samir Gehani]

Can reproduce given se's new set of steps.  

Still would like the two builds between which this regression cropped up.  

Initial investigation points to an RDF problem when two clients are sharing a
datasource.  I think the RDF implementation should handle synchronization rather
than have multiple clients follow some protocol.

Comment 12

[Samir Gehani]

OK, on a new profile I can't reproduce this even using se's new steps.  And I no
longer have an old profile on my debug machine.  

se,
Can you confirm that this doesn't affect new profiles?

Comment 13

[Samir Gehani]

Ignore my last comment.  This bug only affects users in the same browser session
that the MIME-type was created in.  If they restart their browsers the mapping
takes effect.

Comment 14

[sairuh (rarely reading bugmail)]

samir: i restarted the browser, and the user-defined type *still* didn't take
affect. tested using 2001.09.25.03-branch comm bits on OS 9.1 [emul over os x].

Comment 15

[sairuh (rarely reading bugmail)]

drat, i tried with a new profile, and the user-defined pref still doesn't go
into effect after a restart.

Comment 16

[sairuh (rarely reading bugmail)]

hokay, samir and i have narrowed this down to occurring btwn 2001.08.01 and
2001.08.06 trunk [well, pre-0.9.4 branch, anyhow!]. ie, not a prob with
2001.08.01 or earlier bits.

another observation: when going thru these older builds, i found that samir's
workaround to restart the app does work. so, a difference btwn trunk and branch:
branch bits don't offer a restart workaround. alas. :(

Comment 17

[sairuh (rarely reading bugmail)]

samir, i can actually repro this using 2001.08.01.04 [trunk] bits. i'm gonna
look at mozilla builds btwn 7/26 and 8/1...

Comment 18

[sairuh (rarely reading bugmail)]

scratch that --cannot find mozilla bits btwn 7/26 and 8/1.

so, it looks like something was checked in btwn the 2001.07.26.21-0.9.2 [albeit
branch] and the 2001.08.01.04 [albeit trunk] builds that caused this regression.

Comment 19

[Peter Trudelle]

This needs an ETA date in the status whiteboard today.

Comment 20

[Samir Gehani]

Now I simply cannot reproduce this under any conditions on my machine.  I even
tried by serving up a new unused MIME-type (configured my server to serve
application/x-samir for files with .sbg extensions) and this bug simply does not
occur in my setup for 
ns  2001-08-01-04-trunk, 
ns  2001-08-06-04-trunk, 
moz 2001-09-21-03-trunk,
moz 2001-09-26-03-0.9.4, or 
moz 2001-09-18 developer debug builds.

Have a couple of ideas to experiment when se's machine becomes free.  se, have
you been able to reproduce this on any other machine consistently?

Comment 21

[Samir Gehani]

BTW, even the .exe testcase works for me.

Comment 22

[Samir Gehani]

Can't reproduce on pchen's debug mozilla build from this morning.  On Jimmy's G4
I reproduced this once but could not ever reproduce it with the exact same steps
again.  

The problem where the MIME-type mappings don't get deleted from the
mimeTypes.rdf datasource even if they are removed from the helper apps prefs
panel may have something to do with it: as suggested by law, the uriloader may
get a different reference to the mimeTypes.rdf datasource than the one used by
the prefs panel.  

In addition, the two times I have actually witnessed the problem have only been
for the aplpication/octet-stream and exe combination -- one which is unlikely to
be used by mac users.  Although, I admit that the problem can possibly be wider
than just that combination.

Comment 23

[Samir Gehani]

OK, I saw this (only once) while I was debugging and the problem was that
RDFXMLDataSourceImpl::Init(const char* uri) was failing.  Since then I haven't
been able to reproduce this while debugging and hence don't know what was
failing exactly.  Any ideas welcome.  

Comment 24

[Peter Trudelle]

nsbranch-, not widely reproducible, no fix, and too risky to change these areas
at this point.

Comment 25

[Jaime Rodriguez, Jr.]

Removing [PDT] grafitti because this was minused by component team.

Comment 26

[Samir Gehani]

Moving to mozilla0.9.8.

Comment 27

[sairuh (rarely reading bugmail)]

tentatively nominating for nsbeta1.

argle, i was able to reproduce this using a new profile on mac 10.1.2 with
2002.01.25.03 comm trunk bits. however, there were a few times where i *wasn't*
able to repro --but that was with an existing profile.

Comment 28

[Samir Gehani]

Prefs triage team: need a reproducible testcase.

Comment 29

[sairuh (rarely reading bugmail)]

using 2002.06.27.05 branch comm bits on mac 9.1 and 10.1.5, i'm unable to repro
this so far --helper apps that i define from the prefs panel now work. the
application is noted in the dlg, and launchable.

marking wfm --but do reopen if anyone else sees this with recent builds (branch
or trunk).

Comment 30

[sairuh (rarely reading bugmail)]

v.