88066 - Quick redesign of the helper app dialog

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Scott MacGregor]

This is a tracking bug for the helper app changes we made over the last day.
There's another similar bug (86640) where a lot of post mozilla .9.2/.3 planning
is happening on this dialog. I'm going to leave that one alone so they can keep
working on their ideas in that bug. This bug is intended for our simplicications
to the current dialog that we want to land ASAP. 

I'll post the diffs and the screen shot next.

Comment 1

[Scott MacGregor]

Attachment: Changes for the 'new' helper app UI

Comment 2

[Scott MacGregor]

I still have to add the advanced button to this dialog but I'm going to land
this change before adding that so we can start getting some testing immediately
on the trunk. 

Comment 3

[Joe Hewitt (gone)]

r=moi

Comment 4

[Akkana Peck]

Is there any chance that this redesign could include the "Save to disk" button
that's always been missing from the New dialog?  Not many people are going to
figure out the workaround of creating a new type with a bogus app, then clicking
"edit" to get the different dialog that does include "save to disk".

Comment 5

[timeless]

I know this is an interim fix, but please use English in comments not 'b4' 
is there an RFindChar() instead of RFindCharInSet()?

i think i'd use
if (applicationDescription /*!= ""*/)

the whitespace below is inconsistent [both for indentation and foo(bar)]
+         this.updateApplicationName(this.getString("noApplicationSpecified"));
+
+        if ( applicationDescription  && 
this.mLauncher.MIMEInfo.preferredAction != this.nsIMIMEInfo.saveToDisk ) 
//extra trailing white char

Comment 6

[sairuh (rarely reading bugmail)]

i agree with akkana --i've always been annoyed that creating a new type lacked
the "save to disk" option. unless, of course, that could only be deferred for
the Future Redesign.

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: early/preliminary shot from mscott

Comment 8

[Scott MacGregor]

This has been checked into the trunk. minus a couple caveats:
1) Blake gets to add the button to clear the two magic prefs to the helper app
prefs panel.

2) I need to add an advanced button to the helper app dialog


Adding the vtrunk keyword to let sairuh know she can start banging on the new
design in tomorrow's builds. 

Comment 9

[Blake Ross]

(I've got the trivial code for the Clear button, someone just needs to tell me 
where to put it and how to word it).

I'm still confused.  In the meeting, and on the pic I have, I thought we were 
going with the two radiobuttons for Open. What happened?

Comment 10

[Scott MacGregor]

hey blake, we revised that pic during the meeting and got rid of the extra radio
button...

Comment 11

[Blake Ross]

Crap. I apparently missed that, or it was in the first 10 minutes that I missed 
:-/  I kinda thought it was a good idea.

Okay, thanks.

Comment 12

[sairuh (rarely reading bugmail)]

i did some quick testing on a linux mozilla debug from 8:30pm today:

1. went to http://mozilla.org and clicked the mac, linux and win32 build links:
all of them launched the helper app dialog w/save to disk selected [expected].

2. the download progress dialog resulting from (1) didn't appear clipped [both
modern and classic]. yay!

3. i get the following assertion when the progress dialog appears. not sure how
relevant it is, but it only seems to crop up when i'm *not* overwriting an
existing file [interesting, that].

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80520006
(NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isExecutable]"  nsresult:
"0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame ::
chrome://global/content/helperAppDldProgress.js :: setupPostProgressUI :: line
417"  data: no]
************************************************************

4. testing the "Open" feature, no predefined helper app: i went to
http://jrgm.mcom.com/bugs/mimetypes/ and clicked on a file there [eg, the .wav
one]. in the helper app dialog, i selected "Open with...", clicked Choose,
selected /usr/bin/xmms --and then xmms launched.

5. another "Open" test without predefined helper app: after doing (4), i quit
xmms and click on the .wav file again. as expected, the setting in (4) does not
persist, since no helper app was set for mozilla.

6. testing "Open" feature, with predefined helper app: defined a helper app
first in the Preferences > Helper Applications dialog [as mscott mentioned, the
Advanced button will be implemented later] --this time for audio/mpeg [for .mp3
files] to use xmms. went to the same url in (4), clicked on the .mp3 file: the
helper app dialog launched with "Open xmms" selected. clicking OK launches xmms,
too.

7. using the same settings in (6), i turn off the "Always ask before opening
this type of file" checkbox. the next time i click the .mp3 file, i don't get
the helper app dialog [expected].

8. interesting observation after running (7): i went to the Helper Applications
pref panel and checked the settings for audio/mpeg [clicked "Edit"]. the "Always
ask me before opening downloaded files of this type" checkbox is *still*
selected. it should be deselected due to turning it off in (7), right?

9. i've been having the "Keep this window open..." checkbox selected for the
above tests. so, with the same settings from (7), i turn it off. as expected,
the download progress dialog goes away once the .mp3 file is fully loaded [and
xmms still launches].

whew. pardon the long post --but i hope this would serve as a preliminary round
[acceptance/sanity level] of tests for this feature.

let me know if i should file separate bugs for what i saw in (3) and (8) above!

tomorrow i'll test on Mac once the trunk verif bits are available. i won't be in
the office till sometime in the afternoon, so prolly won't be able to get to
win32 bits till then. shrir, if you have any spare cycles, could you check out
how the helper app behaves with the win32 trunk bits? thx!

Comment 13

[Boris Zbarsky [:bzbarsky]]

I'm seeing a problem here...  When I define a helper app in preferences,
everything is fine.  If I have mozilla pick up a helper app from a .mailcap file
(using the patch in bug 52441) however, I see the following problems:

1)  The dialog correctly shows the app filled in but the "Save to Disk" radio
    button is selected.
2)  When the "Open Using" radio button is selected by the user the "OK" button
    becomes inactive.

The code from the patch in bug 52441 basically does the following:
mimeInfo->SetPreferredApplicationHandler(handlerFile);
mimeInfo->SetPreferredAction(nsIMIMEInfo::useHelperApp);
mimeInfo->SetAlwaysAskBeforeHandling(PR_TRUE);
mimeInfo->SetApplicationDescription(NS_LITERAL_STRING("").get());

Should it be setting something differently?  Or is this a problem with the new
dialog?  (the old dialog did not have this problem)

Comment 14

[sairuh (rarely reading bugmail)]

preliminary tests using 2001.06.28.04-trunk comm bits on Mac OS 9.x. more or less 
tested similar things as with linux [differences noted below]... overall, things 
look okay [for an initial pass]. i tested on a machine at home that had a lot of 
Internet Config settings already there, as well as plugins in the System 
Folder:Internet Plug-Ins --i tested with 'em both installed [to see if the helper 
app dialog would pick 'em up] and both removed [to see if i can configure the 
helper apps in netscape6.x].

1. went to http://mozilla.org, and clicked the mac, linux and win32 build links 
to see what would happen. for the mac and linux, there was no helper app defined 
by the system, so "save to disk" was selected [and, saving to disk went fine 
too]. for the win32, StuffIt Expander was defined by the OS, and opening it and 
decompression of the file went as expected [expanded and saved to the system-
default location].

2. the download progress dialog resulting from (1) didn't appear clipped in 
either the classic or modern themes.

3. testing "Open", with system-defined helper app; again test files used are on 
http://jrgm.mcom.com/bugs/mimetypes/ .

test (3a). clicked on the .aiff file [Internet Config has this set to use 
QuickTime *and* i had the QT plugins in the Internet Plug-Ins system folder]. 
results: no helper app dialog, but the QuickTime plugin loaded in the web page 
and played the file [expected, i presume].

test (3b). clicked on the .ram file [Internet Config has this set to use 
QuickTime *and* RealPlayer was installed]. results: the helper app dialog 
launches with "Open with RealPlayer" selected; clicking OK launches RealPlayer 
[expected].

4. testing "Open" without any predefined helper apps or plugins. to do this i 
removed the Internet Config settings for the audio files [buncha them, just to be 
sure], as well as removed the QT plugins from the Plug-Ins folder.

then i clicked on the .wav file. in the helper app dialog, selected the "Open 
with...", clicked "Choose", then selected the QuickTime Player, etc. --and then 
the QuickTime Player launches [expected].

5. another "Open" test w/o any predefined helper app: after doing (4), quit 
QuickTime and click on the .wav again. as with linux, the setting in (4) does not 
persist since it wasn't defined by the user in netscape6.x.

6. testing "Open" with predefined helper app, via Helper Applications pref panel. 
first i defined a helper app for audio/x-wav [for .wav] to use the QuickTime 
Player. went to the same url as the above tests, clicked on the .wav file, and 
the helper app dialog had "Open with QuickTime Player" selected. clicking OK 
launches QT as well.

7. using the same settings in (6), i turn off the "Always ask before opening this 
type of file" checkbox. the next time i click the .wav, the helper app dialog no 
longer appears [expected].

8. as on linux, i wanted to see if the "Edit" dialog still had "Always ask me 
before opening downloaded..." checked: even though this feature is disabled in 
commercial builds at present, the checkbox --as on linux-- *is* still selected. 
well, consistent at least... ;)

9. testing the "Advanced" button: clicked on the .aiff file, then clicked the 
"Advanced" button in the helper app dialog. the "New Type" dialog appeared, 
wherein i put QuickTime as the app for the audio/x-aiff mimetype associated w/
.aiff files. after completing/dismissing this dialog, helper app dialog is then 
updated to show "Open with Quicktime Player" selected. launching the app works 
fine, too.

10. testing the "Keep this window open..." checkbox in the download progress 
dialog: when it's selected, it persists; when it's deselected, it goes away once 
download/transfer is finished.

so, other than (8), the only other issues i ran into during this pass were:

* bug 86533, where the browser window initially loses focus after launching 
another app. :-/
* in (4) after selecting the app via "Choose", the helper app dialog doesn't seem 
to resize properly [in either theme] when filling in the application path and 
name. the right buttons get pushed further downwards [will attach screenshots 
later on]. don't think i saw this on linux since the path was short --might occur 
on win32, though, with long paths.

hopefully will check win32 trunk later today...

Comment 15

[sairuh (rarely reading bugmail)]

akkana et al., the bug to have "save to disk" in the New Type dialog is bug 80557.

Comment 16

[sairuh (rarely reading bugmail)]

Attachment: mac classic helper app dialog w/long path, poorly fit

Comment 17

[sairuh (rarely reading bugmail)]

Attachment: winNT modern helper app dialog w/long path, poorly fit

Comment 18

[sairuh (rarely reading bugmail)]

filed 88320 for the helper app dialog drawing problems w/long application paths.
sorry for the noise here...

Comment 19

[sairuh (rarely reading bugmail)]

filed bug 88330 for the "always ask before..." checkbox state not being
reflected properly [tests (8) for both linux and mac].

Comment 20

[sairuh (rarely reading bugmail)]

baseline/prelim testing on win98 using 2001.06.29.06-trunk comm bits.

overall, basic features seem okay [see details below, if you're curious]. here 
are a few problems i encountered:

* at around test (4) i fiddled with having more than one helper app with the 
same mimetype...and encountered bug 88429. basically, settings are overwritten 
even if i cancel the warning to do so.

* for test (9) i found that i needed to use a different profile, because [i 
think] having the "always ask before" setting off was still being remembered 
--even though i had gone into the pref panel and removed the helper app. i 
presume this will be fixed when the "Clear" button is implemented. my workaround 
was to remove user_pref("browser.helperApps.neverAsk.openFile", 
"application%2Foctet-stream"); from the prefs.js file. filed bug 88435.

* after clicking in the New Type dialog --when brought up by the "Advanced" 
button-- the helper app went away instead of staying up. filed bug 88439.

sidenote: my win98 box at home already has quite a few system-defined helper 
apps/file associations, but i found a couple: .bin and .bz2 files, which can be 
found going thru dirs at ftp://ftp.mozilla.org/pub/mozilla/nightly/ ...

1. sanity test: clicking on the linux, mac and win32 download links on 
http://mozilla.org did result in launching the helper app dialog.

2. the download progress dialog didn't appear clipped in either modern or 
classic themes.

3. testing "Open" with OS-defined helper app: both the linux and win32 download 
links on http://mozilla.org [.tar.gz and .zip files, respectively] resulted in a 
dialog with "Open with WinZip", since WinZip is associated with such files on my 
machine. clicking OK successfully transferred and opened WinZip, too.

4. testing "Open" with no OS-defined helper app, using "Choose": tested clicking 
a link to the mozilla source .bz2 file in the nightly builds site [eg, 
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-06-29-08-trunk/mozilla-source.tar
.bz2]. chose WinZip to open the .bz2 file, which it did.

5. after (4), testing persistence: dismissed WinZip, and clicked the .bz2 link 
again. as expected, the setting chosen in (4) was not remembered.

6. testing with helper app defined from Helper Applications pref panel: defined 
a helper app to open .bz2 files [with mimetype of application/octet-stream] with 
WinZip. the resulting helper app dialog displayed "Open with WinZip" for the 
.bz2 file and launched [expected].

7. using same settings in (6), turn off "Always ask before..." in helper app 
dialog: as expected, the helper app dialog was bypassed, and the .bz2 file was 
transferred and opened with WinZip.

8. check results of (7) in pref panel: encountered bug 88330...

9. testing "Advanced" button: removed the helper app defined in (6) and needed 
to remove the line user_pref("browser.helperApps.neverAsk.openFile", 
"application%2Foctet-stream") in prefs.js [see bug 88435]. after adding the info 
into the New Type dialog [still using WinZip], i clicked OK --but rather than 
returning to the helper app dialog, the latter went away. had to click the .bz2 
file again [see bug 88439]. however, the helper app dialog displayed the new 
setting, and the helper app was listed in the pref panel.

10. testing "Keep this window open..." in download progress dialog: as expected, 
this dialog went away once the transfer was complete.

Comment 21

[Boris Zbarsky [:bzbarsky]]

OK.  Looks like the problem I was having was that the application descriptions
was an empty string.  This dialog behaves _very_ oddly when that's the case (and
gives no useful error messages).

Comment 22

[sairuh (rarely reading bugmail)]

hrm, i might've jumped the gun saying that the download progress dialog looks
fine these days [per tests (2) above; covered in bug 79889]... using a mac
mozilla build from 2001.06.29.04-trunk, the dialog [at least in modern] was
clipped on the right side. *sigh* will test later on with more recent builds...

Comment 23

[esther]

In testing this with mail, I can't see how to turn on the "Always ask before
opening this type of file".  I unchecked it to see that it works, but can't find
a place to enable this dialog again.  I checked the Preferences for Helper Apps
but can't find anything there to turn this on. Since I didn't assign a helper
app to open .xls files, I only asked that it use the system settings I don't
have it listed in the helper apps bucket so there is nothing to edit.
Is this by design?  

Comment 24

[Scott MacGregor]

esther, that part of the design is 88435

Comment 25

[Boris Zbarsky [:bzbarsky]]

Bug 89414 filed on the strange behavior with a blank application description

Comment 26

[scottputterman]

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

Comment 27

[sairuh (rarely reading bugmail)]

methinks the baseline testing i've done here is enough to verify this as fixed
on the trunk. anyone mind that i remove the vtrunk kw? let me know if there are
other areas that need coverage that'd be relevant to this particular
bug/redesign. [i've filed issues i've found separately].

Comment 28

[Scott MacGregor]

I've checked this into the branch. 

Comment 29

[basic]

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

Comment 30

[sairuh (rarely reading bugmail)]

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

linux - 2001.07.09.04
winnt - 2001.07.09.05
mac - 2001.07.09.03

other issues have been/should be filed separately. :)

Comment 31

[Akkana Peck]

"Always ask me" is still greyed out -- this never actually got fixed (on Linux,
at least).  I can't find any other bug covering this dialog, but if there is
one, please point me in the right direction.  Thanks.

Comment 32

[Scott MacGregor]

can you file a new bug for that. This bug is fixed. We redesigned the dialog.

Comment 33

[sairuh (rarely reading bugmail)]

v.

other issues are/should be tracked in seperate/new bugs.