Closed
Bug 225574
Opened 22 years ago
Closed 21 years ago
When trying to select an application to use in the Open with dialog / Download window / Preferences window, applications are greyed out
Categories
(Toolkit :: Downloads API, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.7.5
People
(Reporter: magervalp, Assigned: bugs)
References
()
Details
(Keywords: fixed-aviary1.0)
Attachments
(1 file, 2 obsolete files)
4.89 KB,
patch
|
jhpedemonte
:
review+
sfraser_bugs
:
superreview+
asa
:
approval-aviary+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7
When you click on a link with an unhandled mime type, you get a dialog with the
options of opening with an application, or saving the file to disk. When
selecting Open with, choosing the default Other... option in the menu, it gives
you a list of the Applications folder where you can select the application to
use. Almost all applications are greyed out and can't be selected - only a few
random applications are available.
Reproducible: Always
Steps to Reproduce:
1. Click on a link leading to an unhandled mime type
2. In the dialog window choose Open with and select Other...
3. and you get lots of greyed out applications that you can't choose.
Actual Results:
Not an awful lot, really.
Expected Results:
Allowed me to select an application to use to open the link.
Comment 1•22 years ago
|
||
wfm Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b)
Gecko/20031208 Firebird/0.7+. have you tried a more recent build?
Comment 2•22 years ago
|
||
*** Bug 226785 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
ugh, this just happened to me, but i got no options in the dropdown at all.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031215
Firebird/0.7+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed: I've seen this happen quite often, but have always thought this was
an OS X issue (e.g. the OS only allows applications that can actually handle the
file/mime type to be selected).
I have a specific problem with this, relating to Real Player files. Firebird
downloads the file but then says that the default app cannot be found. I have
Real Player. So i decided to choose another app and then find RP myself. But all
the applications were greyed out.
OS X behaviour is as follows. If you attempt to open a file that OS X doesn't
recognise it asks you to select an application to open it in. When the window
pop up, there are 2 drop down menus. The default shows all recommended
applications, and the usual scenario is that they are all greyed out, as with
Firebird. BUT, there is a second drop down menu that allows you to choose any
application. Pick this and the apps are no longer greyed out. Firebird needs to
replicate this behaviour.
Comment 6•22 years ago
|
||
This is also a problem when setting your download preferences. When setting the
action to take when a given mime type is encountered, there is a radio button
for "Open Them in This Application..." which brings up a window to manually
select an app, but lots of valid options are greyed out (.mpeg can't be opened
with Quicktime Player, .pdf can't be opened with Preview, etc.)
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Firebird0.9
Comment 7•21 years ago
|
||
This bug persists in Firefox 0.8, making it difficult/impossible to (among other
things) open up m3u (application/mpegurl) playlists in, say, Audion 3.
Comment 8•21 years ago
|
||
Or have .dmg files auto-mount. Every time I download a .dmg, I get a dialog with
one option: Save to disk. The option to open with an application is there, but
it's an empty popup menu, and I can't do anything with it.
Comment 9•21 years ago
|
||
*** Bug 232758 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•21 years ago
|
Assignee: firefox → bugs
Status: ASSIGNED → NEW
Target Milestone: Firefox0.9 → Firefox1.0beta
Comment 10•21 years ago
|
||
Also greys out OK option, so downloads it is not possible to initiate downloads at all! Happens
always, on 16 March trunk
Updated•21 years ago
|
Flags: blocking0.9?
Comment 11•21 years ago
|
||
This is targetted for 1.0beta, so it doesn't block 0.9.
Flags: blocking0.9? → blocking0.9-
Updated•21 years ago
|
Flags: blocking1.0?
Comment 12•21 years ago
|
||
Ditto to everything said here. Started with a problem in trying to select
Acrobat Reader 6.0 instead of the not-installed 5.0 for pdf files. When I
deleted personal profile and installed the latest nightly upgrade of Firefox,
now there are NO helper applications listed and nothing is choosable. Help!
Comment 14•21 years ago
|
||
*** Bug 236807 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•21 years ago
|
Flags: blocking1.0? → blocking1.0+
Comment 15•21 years ago
|
||
Is this at all related to the Thunderbird bug 232220
Comment 16•21 years ago
|
||
I (In reply to comment #15)
> Is this at all related to the Thunderbird bug 232220
Yes, I believe so. According to my observation, application is grayed out when
it is a 'bundle' (opposed to a binary file) which is a MacOS specific concept.
See comment in Thunderbird bug. For contributors, I also included a dev link to
apple doc related to bundles.
Comment 17•21 years ago
|
||
*** Bug 222563 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
*** Bug 244368 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.0+ → blocking1.0mac+
Target Milestone: Firefox1.0beta → Firefox1.0Mac
Comment 19•21 years ago
|
||
*** Bug 244898 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
This patch instructs the open dialog box to display packages if it finds the
"..apps" application flag in the requested filters. That works for selecting
applications and should ease people's pain, but in debugging this I found that
mac/nsFilePicker.cpp is in pretty bad shape generally. Though it tries to
process the filter list, it ends up ignoring the results and allows any file to
slip through. (At least on my computer it does.) Consequently, you can choose
any kind of file as your helper application, or open any file (except a
package) through the normal file open dialog. But those are other bugs.
Comment 21•21 years ago
|
||
Didn't see the whitespace and missing file bit in the last patch; this is a
cleaned up version. I wonder if this could go into .9? The bug it fixes is
pretty detrimental on mac.
Updated•21 years ago
|
Attachment #149922 -
Attachment is obsolete: true
Updated•21 years ago
|
Attachment #150004 -
Flags: review?(bugs)
Comment 22•21 years ago
|
||
*** Bug 245178 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
*** Bug 246515 has been marked as a duplicate of this bug. ***
Comment 24•21 years ago
|
||
*** Bug 239328 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
Can we get target this for 1.0 beta and set blocking statius for 1.0? I
understand that Mac interface bugs are not a priority until after 1.0 is out the
door, but this is a pretty detrimental bug with a ton of duplicates out there.
Furthermore, it has a working patch that only touches Mac code, just waiting to
be checked in.
Flags: blocking1.0?
Updated•21 years ago
|
Flags: blocking1.0? → blocking1.0+
Updated•21 years ago
|
Flags: blocking1.0+ → blocking1.0-
Comment 26•21 years ago
|
||
Comment please, Blake or anyone? I've done my best to find the criteria you are
using to make these decisions (not blocking 1.0) and can't come up with
anything. Thousands of Mac users are downloading this applicantion, why can't
this bug (with a patch ready to be checked in) be fixed? If the plan is "ignore
all Mac bugs until after 1.0" you ought to say that in the roadmap so it can be
properly debated.
Comment 27•21 years ago
|
||
Nathan, the plan is to ship Firefox 1.0 for Mac after the Linux and Windows
versions come out. Thus, there's no reason for this to be marked as blocking 1.0
(for win/linux) in addition to 1.0 mac.
Comment 28•21 years ago
|
||
I understand that there is a special Mac release after 1.0, but I don't see why
this bug can't at least be targeted for Firefox1.0beta. The way I read the
roadmap, it postpones work on minor Mac UI bugs. Fine, but this bug is more
serious than that, and it has a patch waiting for review already. Refusing to
even look at it feels more like procrastination than triage.
Comment 29•21 years ago
|
||
I do not know if what I have encountered recently is related, but suspect that
it may be or may be involved in the same general area.
I noticed that FF 0.9.1+ (trunk) failed to open a window to allow me to direct
the download to a specific folder on or about the 20040719 build (I have reset
and changed the preference on several occasions to see if it would reset itself
which it has not), but I suspect that the problem may have existed prior to
that. The reason that I am uncertain is that on or about that date I trashed
the profile which I had been using for quite some time through various nightly
builds and so on because the passwords were now stored in a different file and I
was unable to view passwords because of some sort of problem with the
profile...there may also have been something in the profile which hid the
problem I now encounter. After several days there will be a VERY occasion
occurrence where the pop up window to select "Open with" or "Save to Disk" (and
then select the location to save it to) will pop up, but this is such an unusual
occurrence as to be surprising when it does happen.
I have since tried using the branch build on this profile and the same thing has
happened though I am uncertain as to whether this is due to the problem existing
in the 0.9.1+ Branch Nightly Builds or whether the Branch does not like being
run on the Trunk's profile.
In any event, I am posting this note so that others may evaluate whether this is
a related matter or should be posted as a separate bug.
I am using OS X 10.3.4
Thanks
Comment 30•21 years ago
|
||
Can this *please* be checked in? It should also resolve a very annoying problem
for Mac Thunderbird users who have to deal with attachments. It's only a dozen
lines of code change. It just doesn't make sense to let one product's road map
dictate fixes in others, especially when they resolve a common, well-defined
problem. This bug has had a lot of dupes, and ten votes.
Drivers, remember your Mac user base!
Comment 31•21 years ago
|
||
The bug has a patch, requesting to block aviary 1.0 in general...
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Assignee | ||
Comment 32•21 years ago
|
||
blocking-aviary1.0mac is good enough to halt the mac release.
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Comment 33•21 years ago
|
||
(In reply to comment #32)
> blocking-aviary1.0mac is good enough to halt the mac release.
We understand that, but would appreciate it being fixed before then. Eg, in the
1.0 PR. If NO platform-specific bugs are being fixed until after 1.0, then I can
live until then, but I don't think that's the case. Mac users are clearly being
singled out on this one. It's even more egregious since the patch already
exists, and has for almost two months. I encounter this bug daily in Thunderbird.
Comment 34•21 years ago
|
||
Here's one thing: if you put off every mac bug until the "mac" release, you're
guaranteeing that release to be a failure. There is no way we can fix,
incorporate, and test the piled-up mac bugs from the past 6 months in one release.
The policy states that UI (polish) bugs should be postponed until then. Fine,
who cares about those? This bug is a different animal, yet people are using that
policy to ignore it (and presumedly every mac bug) until the blessed PC / Linux
release is finished. It's a dishonest (or ignorant) application of the policy,
and the result of your actions is that after labouring to fix this bug I've
given up on contributing. The way your actions logically produce that result, I
have to assume it's by design.
When this "screw mac" policy expires, if it ever does, will any mac programmers
come back from exile?
Comment 35•21 years ago
|
||
*** Bug 258440 has been marked as a duplicate of this bug. ***
Comment 36•21 years ago
|
||
*** Bug 242116 has been marked as a duplicate of this bug. ***
Comment 37•21 years ago
|
||
*** Bug 256741 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: When trying to select an application to use in the Open with dialog, applications are greyed out → When trying to select an application to use in the Open with dialog / Download window / Preferences window, applications are greyed out
Comment 38•21 years ago
|
||
Comment on attachment 150004 [details] [diff] [review]
Same as before, but without the whitespace change
Javier, may you have a look at this one?
Attachment #150004 -
Flags: review?(bugs) → review?(jhpedemonte)
Comment 39•21 years ago
|
||
Nathan, I'm not sure about looking for the ".app" extension directly. What about instead using
|LSCopyItemInfoForRef()| to get info for the file system item (such as in Listing 3-6 of http://
developer.apple.com/documentation/Carbon/Conceptual/ProvidingNavigationDialogs/nsx_tasks/
chapter_3_section_5.html#//apple_ref/doc/uid/TP30001147-CH203-BEIBEAHH, then looking if the
|LSItemInfoRecord| has the 'kLSItemInfoIsApplication' flag set?
Comment 40•21 years ago
|
||
*** Bug 260477 has been marked as a duplicate of this bug. ***
Comment 41•21 years ago
|
||
(In reply to comment #39)
> Nathan, I'm not sure about looking for the ".app" extension directly. [...]
The patch doesn't look for the .app extension. Its looking for an "..apps" flag
set beforehand, somewhere else. Don't ask me where that happens; it's been
months since I submitted this patch or looked at the mozilla source.
Comment 42•21 years ago
|
||
Does anyone know if there is a timeline for getting this problem fixed?
Comment 43•21 years ago
|
||
*** Bug 260401 has been marked as a duplicate of this bug. ***
Comment 44•21 years ago
|
||
(In reply to comment #41)
> Its looking for an "..apps" flag
Ah, right you are. Found it.
Is there any reason why we shouldn't be doing the 'kNavSupportPackages' flag all
the time? The code would be simpler if we just enabled that flag all the time.
Comment 45•21 years ago
|
||
Simple patch based on Nathan's patch. I figure we should just be enabling
packages everytime. Don't see a reason not to. If you've got a build, test
this patch out.
Attachment #150004 -
Attachment is obsolete: true
Comment 46•21 years ago
|
||
Comment on attachment 160394 [details] [diff] [review]
Simple patch
I'd like to get this in as soon as possible, especially for Firefox 1.0.
As Nathan found, the filter proc doesn't work at all. I'd like to fix that
correctly before closing this bug out.
Attachment #160394 -
Flags: superreview?(sfraser)
Attachment #160394 -
Flags: review?(peterv)
Comment 47•21 years ago
|
||
(In reply to comment #45)
> Created an attachment (id=160394)
> Simple patch
>
> Simple patch based on Nathan's patch. I figure we should just be enabling
> packages everytime.
File->Open File?
Comment 48•21 years ago
|
||
Comment on attachment 160394 [details] [diff] [review]
Simple patch
Ha! Thanks mano. Sometimes I miss the simplest of things.
Attachment #160394 -
Attachment is obsolete: true
Attachment #160394 -
Flags: superreview?(sfraser)
Attachment #160394 -
Flags: review?(peterv)
Comment 49•21 years ago
|
||
Comment on attachment 150004 [details] [diff] [review]
Same as before, but without the whitespace change
So this patch will work for now! The only thing I would change right now is:
- PRBool mAllFilesDisplayed;
+ PRPackedBool mAllFilesDisplayed;
+ PRPackedBool mApplicationsDisplayed;
Otherwise, looks good. As I mentioned, I'm looking at rewriting the filter
proc, but I'm not sure I'll have that done before Firefox 1.0.
Attachment #150004 -
Attachment is obsolete: false
Attachment #150004 -
Flags: superreview?(sfraser)
Attachment #150004 -
Flags: review?(jhpedemonte)
Attachment #150004 -
Flags: review+
Comment 50•21 years ago
|
||
Comment on attachment 150004 [details] [diff] [review]
Same as before, but without the whitespace change
Agreed on use of PRPackedBool.
Attachment #150004 -
Flags: superreview?(sfraser) → superreview+
Comment 51•21 years ago
|
||
Comment on attachment 150004 [details] [diff] [review]
Same as before, but without the whitespace change
asking approval.
Attachment #150004 -
Flags: approval-aviary?
Comment 52•21 years ago
|
||
Comment on attachment 150004 [details] [diff] [review]
Same as before, but without the whitespace change
a=asa for aviary checkin.
Attachment #150004 -
Flags: approval-aviary? → approval-aviary+
Comment 54•21 years ago
|
||
(In reply to comment #53)
> Checked in to trunk and aviary.
marking fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 55•21 years ago
|
||
Opened bug 263332 to deal with the filter proc.
Comment 56•21 years ago
|
||
*** Bug 263350 has been marked as a duplicate of this bug. ***
Comment 57•21 years ago
|
||
has this fix been incorporated into a nightly build that is available for
download yet?
Comment 58•21 years ago
|
||
*** Bug 264012 has been marked as a duplicate of this bug. ***
Comment 59•21 years ago
|
||
*** Bug 263710 has been marked as a duplicate of this bug. ***
Comment 60•21 years ago
|
||
*** Bug 267347 has been marked as a duplicate of this bug. ***
Comment 61•21 years ago
|
||
*** Bug 267484 has been marked as a duplicate of this bug. ***
Comment 62•21 years ago
|
||
*** Bug 266494 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Target Milestone: Firefox1.0Mac → Firefox1.0
Comment 63•21 years ago
|
||
*** Bug 268253 has been marked as a duplicate of this bug. ***
Comment 64•21 years ago
|
||
*** Bug 268319 has been marked as a duplicate of this bug. ***
Comment 65•20 years ago
|
||
cleanup:
Verified with Mac Tbird trunk build 2005-08-04-09-trunk
Status: RESOLVED → VERIFIED
Updated•17 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•