There are some text formatting and focus ring issues in the helper app dialog, and it is a little too wide. Also, the keyset id is wrong so keybindings don't work. Here's a patch to address the issues:

Bill, can you review this? Alec, sr?

I'm worried that splitting up the "intro" into those smaller pieces might box in translators. Do you think it's OK to impose that ordering? What's the benefit of splitting this up this way? I might go for it it if fixed the redisplay problems (bug 79543).

your tabs are all messed up in your XUL, but the rest looks ok to me.

(just noticed bill's comments - didn't realize that was going on ... the validity of my sr= is pending bill's approval of course)

I considered i18n issues, but figured that separate elements was only really following an ordering in the english version. The patch implements a field-like UI: Name Value Download: <what> from: <where> In the english translation, it happens to read like a sentence, and in other translations this is probably possible too. In a language where this is not possible, it's alternatively possible to specify what and where from as above.

btw, the patch is a whitespace-indifferent diff, which explains the weird indentation

I applied your patch but the dialog doesn't work right. E.g., I see only applicatioin/octet-stream temp from #1 at the top (where I expected to see "You have downloaded a file..."). Also, If "Save to disk" is selected under "Use a different action for this file", but "Use default action for this file" is selected, then for some reason the radio button next to "save to disk" is invisible. My diffs seem to match your patch so I don't think it's something I did. It seems like you'd have to do more code changes to deal with the different xul structure and the composition of that intro text.

Hm, well since we're under i18n freeze anyhow, let's just ignore my wording changes. I'll produce another patch that just modifies the layout, and we'll see if that works...

Aside from the wording, the dialog is too narrow using Modern on the Mac. All of the buttons on the right are cropped out, including "OK" which makes the dialog useless. Doing this: Index: mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.xul =================================================================== RCS file: /cvsroot/mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.xul,v retrieving revision 1.3 diff -u -2 -r1.3 nsHelperAppDlg.xul --- nsHelperAppDlg.xul 2001/04/16 22:04:24 1.3 +++ nsHelperAppDlg.xul 2001/05/16 23:24:40 @@ -41,5 +41,4 @@ title="&caption.label;" onload="dialog.initDialog()" - style="width: 40em;" class="dialog" align="vertical"> at least makes the dialog intrinsically sized and it works.

display bugs that are related here: * bug 79236 covers clipped buttons/textfields in this [helper app/download] dialog. * bug 79889 covers clipped stuff in the download progress dialog. * bug 79543 covers poor painting of the helper app/download dialog [and edit/new mime dialog] after dismissing the edit/new mime dialog.

OK, I have some better ideas here. Will post a new patch soon that fixes these issues and some others (like half the dialog UI getting shunted offscreen when there's a long file path)

Nav triage: I recommend this not be pushed back because of unaddressed layout issues that can frequently cause content to be pushed offscreen in this window. Setting duration to full day for revised XUL + testing.

again, remind you that german translation may need 150% of the space used by English becuase German sentance is usually longer. add rchen@netscape.com and msanz@netscape.com to the cc list.

style="width: 40em;" may not work for german translation. Again, the goal for mozilla translation is not touching xul but only property file and dtd file. Please do not hard code size in xul based on English assumption.

Adding danielmc and rsmyth to cc: list.

I plan to replace the path sections with readonly edit fields. the width of 40em shouldn't matter as text will wrap and the dialog will become as tall as it needs to be to accommodate more text.

If this isn't the place for this, let me know and I'll open a new bug. When typing the application name into the last field in this dialog, entering trailing spaces (and I presume leading spaces) leads to "Application not found" Trailing and leading spaces should be removed. Linux, 2001061308

Setting ETA. Estimated duration - 1-2 days. Need to: a) convert fields with variable length text to use readonly text fields b) Modify layout slightly.

As per PDT discussion, moving P3 to mozilla0.9.3.

nav triage team: Pushing out to mozilla1.0 since we're redoing the helper app dialog

the bug for redoing the helper app dialog is bug 86640.

nevermind

v