Bug 57610 fixed "download filename not available" by adding it to the title bar, but this fix isn't going to fly for X. The download dialog is a transient window (as it should be), and as such, HAS NO TITLEBAR under most window managers. ICCCM says: "The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction."

spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)

--> default owner

Mass moving bugs that won't get fixed this milestone.

Note to self: This is a helper app dialog problem, not progress dialog.

nsbeta1+ per ADT triage team

the filename is not displayed in the helper app dialog. that is this bug, yes? if so, this problem isn't limited to linux/unix, since i see it on win2k and mac 10.1.3 as well. however, the filename *is* displayed in the download progress dialog, on all platforms. just need to select and scroll (well, drag) to the end of the "To:" field to see it.

> that is this bug, yes? yes. > this problem isn't limited to linux/unix, since i see it on win2k and mac > 10.1.3 as well It should be in the titlebar on those platforms. On UNIX, this dialog does not (and should not) have a titlebar.

This adds a <description> to the dialog, with hidden="true". I added .js code to look for *nix platform (by looking for "X11" in navigator.appVersion) and if so, sets this description to the same string as goes into the title on other platforms, and, unhides the <description> element.

mpt, what's the behaviour on Mac supposed to be?

Comment on attachment 72532 [details] [diff] [review] patch, v1.0 r=sgehani

nsbeta1- per ADT triage team

Comment on attachment 72532 [details] [diff] [review] patch, v1.0 Why is this fix platform-specific? Why not put the filename in the dialog on all platforms? See also mpt's UI spec in bug 86640; I much prefer it to what this would look like....

Is this now fixed with the checkin for Bug 86640? I see the filename in the window title in the Helper Application dialog in recent builds.

This bug is about the case when there _is_ no window title (common on Linux).

ok, I have a patch to make the text in this dialog (first two paragraphs) more like mpt's spec in that bug. bz, should I keep the URL in the dialog? Does anybody care where the download comes from?

> Does anybody care where the download comes from? Anyone who cares half a whit about security does... Opening a Word document from file:///something is one thing, opening one from http://randomsite.com is another.

bah, security. who needs that :) (not like remote content can link to file: uris. anyway...) So here's another suggested patch. You're welcome to suggest another wording, I'm not sure I like it.

taking bug (for those who don't want to read the patch - I am still displaying the url)

this is how mozilla looks like with the patch

-<!ENTITY prompt.label "What should #1 do with this file?"> +<!ENTITY prompt.label "You can choose an application to open the file with, or you can save it to disk."> Why this change? Other than that, I think I like it.... (though all this code should really be rewritten to use stringbundles and formatStringFromName; but that is a separate kettle of fish).

oh, I didn't like mentioning mozilla in both paragraphs, so I figured I'd take mpt's suggestion for that paragraph, too. I can leave it alone, if you prefer.

Well, that UI spec is somewhat broken there (eg it has a "View As Text" button that's hard to reconcile with that wording...) I'd rather leave that part of the wording as-is (though I admit that mentioning &brandShortName; twice is a little odd...)

ok then, leave the second paragraph unchanged

Comment on attachment 113923 [details] [diff] [review] patch (I really wish bugzilla would automatically clear review requests from obsolete attachments)

Comment on attachment 113925 [details] [diff] [review] patch v2 sr=jag

Checking in components/ui/helperAppDlg/nsHelperAppDlg.js; /cvsroot/mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js,v <-- nsHelperAppDlg.js new revision: 1.47; previous revision: 1.46 done Checking in components/ui/helperAppDlg/locale/en-US/nsHelperAppDlg.dtd; /cvsroot/mozilla/embedding/components/ui/helperAppDlg/locale/en-US/nsHelperAppDlg.dtd,v <-- nsHelperAppDlg.dtd new revision: 1.8; previous revision: 1.7 done

Verified on the Win32 2003-03-13-04 trunk and OS X Mach-O 2003-03-13-03 trunk builds.