bug 67001 won't be fixed soon, so we ought to remove the Reveal Location and Launch File buttons in the download progress dialogs for unix builds.ie, for the branch builds at least.

when bug 67001 is fixed, this can prolly be removed as a dep and resolved.

It looks like 67001 is not going to be resolved anytime soon. Sigh. Anyhow, I see these light up (not grey as described elsewhere), so we need to grey them or remove them for UNIX.

has anyone decided how this should work for MacOS X? I'm using 2001-09-05-05, and the button doesn't work.

benc, see bug 91871.

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. :)

-->law

->mozilla0.9.9 Plan to remove on Linux; please address MacOS X in another bug.

I can't test this patch right now because for some reason the download dialog doesn't come up at all for me with current CVS (regardless of this patch). Will try to test it later.

Comment on attachment 56608 [details] [diff] [review] Proposed, untested, patch to remove the buttons. You can't just remove the code, there are other platforms that use this code, like Windows and MacOS. Even BeOS implements this.

Oops, sorry. For some odd reason I thought I was in a unix-subdirectory:-) Any hints on how this could be done to only affect UNIX?

nominating nsbeta1, if bug 67001 isn't fixed in time...

Working on this stuff next.

nsbeta1+ per ADT triage team. Bill, is there someone else who could do this/

Yes, it's not hard; just requires a minimum of xul/js expertise. The simplest fix would be to add code to nsProgressDialog.js to test navigator.platform for Unix (!mac && !windows) and hide those buttons. I think it would be nice to go the extra step of wiring up the "reveal location" button so that it opens a browser window on the parent folder. Then the user would have some chance of doing something with the file.

um. beos implements these features, don't use the wrong logic for the if. [i can't remember if QNX does, but it certainly could]

-> me

Blake, here's the work I did on this.

ADT3 per ADT triage team.

hm, I did it slightly differently in download manager, but since you've already got a patch...

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to target milestone 1.0.1. Please confine your attentions to driving down our list of TM 1.0 bugs for beta. Better to help, debug, or test one of them than fix one of these.

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

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

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

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

Shall we fix this in branch since branch still has this bug.

Just don't enable those two button after download.

=>

The runningOnUnix function needs to also check for "aix" in the navigator.platform string. The suggested patch for the branch only checks for "unix", "linux", and "sun".

Comment on attachment 91924 [details] [diff] [review] patch against MOZILLA_1_0_BRANCH branch ugh these patches are ugly, unless every unix platform does return "unix". If this is not the case, then we really need to make this unix friendly and throw everything... aix, hp-ux, tru64/osf, beos....

Yeah, I'm a little queasy about checking specific platforms but I understand the reason. Is there a way we could actually check whether the Launch / Reveal functionality will be heeded directly? That would be more accurate if there was such a thing. I'm a little confused about this too, is this only for branch? I don't see anything that says this was fixed on trunk.

I don't know if there is a better way to do this, but perhaps this could be done as a pref. Add something like this to all.js: pref(general.show_launch_reveal_buttons, "true"); or pref(general.enable_launch_reveal_buttons, "true"); And then turn it off in unix.js. Would this be a suitable alternative?

jkeiser, Yes, this is only for branch. Because trunk doesn't have this dialog, they are using download manager now.

A new patch using pref setting to disable these two buttons

Comment on attachment 92538 [details] [diff] [review] patch (MOZILLA_1_0_BRANCH) r=jkeiser, slick man, slick :)

Comment on attachment 92538 [details] [diff] [review] patch (MOZILLA_1_0_BRANCH) Put a try/catch around getting the prefservice and the prefvalue, and default enableButtons to 'true' in the JS. With those changes, sr=bzbarsky

Comment on attachment 92543 [details] [diff] [review] patch with bz's comments. (against MOZILLA_1_0_BRANCH) carry r&sr

Same as previou patch, just for trunk

Since bz told me that download manager can be custom in preference. That's mean this bug also happen on trunk if the user don't use download manager and just use download progress dialog.

Comment on attachment 92551 [details] [diff] [review] patch same as previou one but for Trunk(07/22) a=asa (on behalf of drivers) for checkin to 1.1

// Activate reveal/launch buttons if we are enable them. I can't understand this comment. Can you fix it? I suppose you want some other verb than "are"

Comment on attachment 92551 [details] [diff] [review] patch same as previou one but for Trunk(07/22) r=jkeiser on the trunk too. Not sure if we strictly *need* to r-r= and sr=.

Comment on attachment 92551 [details] [diff] [review] patch same as previou one but for Trunk(07/22) carry bzbarsky@mit.edu's sr since it do the same thing with previou patch. And I will change the comments when check in. Should be like this "Activate reveal/launch buttons if we enable them"

checked in trunk

Comment on attachment 92543 [details] [diff] [review] patch with bz's comments. (against MOZILLA_1_0_BRANCH) Approval granted for branch. Change mozilla1.0.1+ to fixed1.0.1 when checked in.

checked in branch(MOZILLA_1_0_BRANCH) yesterday

the buttons are now disabled, but not hidden. i presume that's the expected behavior, yes? tested with 2002.08.15.07-1.0 bits on linux rh7.2.

as with the branch build, Reveal Location and Launch File are disabled (but not removed) during and after file has downloaded. vrfy'ing with 2002.09.19.08 comm trunk on linux rh7.2.