no "open with" dialog box in firefox for application/octet-stream
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Medium
|
|||
firefox (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: firefox
There is currently a bug in firefox upstream where the "open with" dialog box will not appear for application links being sent as application/
https:/
See the "testdownload" link on the bug report page for an example of what I'm talking about:
https:/
Mozilla has acknowledged it is a problem (since 2006!) and will be fixed but that scheduled launch will be for mozilla 1.9.3, which is firefox 3.7.
I'm trying to get my organization migrated over to Ubuntu but this firefox bug in combination with needing to be able to handle several attachments from zimbra creates a problem. I've already patched their current firefox (3.6.3) with the following patches and it has been running solid for months now.
Below are links to the appropriate patches to make this work as it should (I guess I can't upload more than one patch at a time?). I would appreciate it if Ubuntu would please consider applying the patches to their firefox package so we can get this working as it should.
nsMMEInfoUnix.patch
https:/
nsOSHelperAppSe
https:/
Thank you,
Tyler
Related branches
In Mozilla Bugzilla #327323, Ria-klaassen (ria-klaassen) wrote : | #2 |
The Open With extension has this functionality.
In Mozilla Bugzilla #327323, Sunny (sloncho) wrote : | #3 |
This problem still exists in Firefox 3.0 on Linux (opensuse 11.0). With FF3 on windows, it allows to select "Open with..."
In Mozilla Bugzilla #327323, Sunny (sloncho) wrote : | #4 |
Created an attachment (id=328399)
"Open" dialog after selecting known type, send as application/
Still in Firefox 3 it recognizes the file type, but because of the bad mime type send (application/
In Mozilla Bugzilla #327323, Sunny (sloncho) wrote : | #5 |
I tested it on Ubuntu 8.04 live cd, and it has the same problem - so it looks like this Firefox 3.0 for linux only, as on windows it works OK.
Also, I did not have this problem with opensuse 10.3 and firefox 2.0, so looks like a regression.
In Mozilla Bugzilla #327323, Chris Fletcher (fletch-brightsparks) wrote : | #6 |
I can confirm that this still isn't fixed under Ubuntu 8.04.1. Hope somebody can fix it as returning the office workstations to windows is undesirable! (Had a lot of complaints).
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #7 |
Created an attachment (id=334071)
testdownload
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #8 |
Ok, I had a short look at why application/
Currently (Firefox 3.0.1) if the mime-type is application/
If that simplified wouldn't be used "Open" would still be denied because of:
// We don't let users open .exe files or random binary data directly
// from the browser at the moment because of security concerns.
(that's a source code comment and so it seems that this behaviour/
The overall question is if the HelperAppService is supposed to return a default handler for the recognized file extension if application/
Anyway there is a quick'n'dirty workaround to get a usable download UI back:
Add for example the following line to your ~/.mailcap:
application/
By doing that the HelperAppService returns a default application (/bin/true) and the above constraints don't apply anymore. So you'll also get back the other alternatives returned by the MIMEInfo.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #9 |
Given that on Windows FF3 offers immediately to open such a download with the right application (testdownload above is suggested to be opened with Adobe Reader) it's seems to be ok to fall back to the extension mapping and ignoring the application/
So the solution to this issue on Linux would be to make sure that (in addition to mime-types/mailcap also Gnome VFS should return a default application when there is none for the server defined mime-type.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #10 |
Indeed, on Windows FF3 works as expected. Sorry, to say that, but your quick'n'dirty solution, doesn't work proberbly. I can see, that the Firefox suggets, /bin/true for the download, and if you press OK, nothing happens (the default application doesn't open it).
Tested it on two fresh Installations of OpenSuSE 11.0 and Firefox 3.0.1.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #11 |
It depends. /bin/true doesn't open the application obviously but on my system I get a second offer (evince as PDF reader for the attached testcase) which works correctly. If you get no choice I wonder if you have a handler application which is known to gnome-vfs.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #12 |
Created an attachment (id=334319)
nspr logging for HelperAppService with the attached testcase
Just for completeness an NSPR log created with FF 3.0.1
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #13 |
(From update of attachment 212006)
FF3 is showing a different dialog, so obsoleting this
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #14 |
(From update of attachment 328399)
Screenshot shows a dialog which is modified by an addon.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #15 |
Created an attachment (id=334460)
Picture with enabled /bin/true for octect-stream in ~/.mailcap
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #16 |
I don't get a second choice for your testfile. I made a screenshot for that: https:/
>If you get no choice I wonder if you have a handler application which is known to gnome-vfs.
I don't use gnome-vfs at all, maybe you can tell me if I need to install another program for handling the files correctly from firefox!?
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #17 |
Yes, sorry, I got a second choice for another reason.
I have a patch in hand which would fix this issue. I want to discuss it first with mozilla people though.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #18 |
Created an attachment (id=334521)
possible patch
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #19 |
(From update of attachment 334521)
This patch checks if we can get a default handler for the extension if we haven't found one for the type. And if so, we set the type to the extension match.
This is technically pretty obvious but I wonder if that is the "right thing" to overwrite a valid server provided type.
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #20 |
I'm not sure I follow this patch. Apart from crashing when miByExt is null, what happens? Currently, if miByExt has a default handler there are two options:
1) Have a retval. In this case, we CopyBasicDataTo and return miByExt.
2) No retval. In this case we're hitting the SetMIMEType code already.
So the patch only affects behavior in the case when we have both retval and miByExt. But all it changes is to call SetMIMEType instead of CopyBasicDataTo,
Is CopyBasicDataTo clobbering the default app somehow in this case?
As far as the "right thing" bit, the point of this function is to use both type and extension to get our best guess of how to handle. So we certainly want to use the default app for the extension if there isn't one for the type!
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #21 |
Created an attachment (id=334557)
patch #2
> I'm not sure I follow this patch. Apart from crashing when miByExt is null,
> what happens? Currently, if miByExt has a default handler there are two
> options:
oops, sorry for the crash. Should be fixed now.
I think this patch works but probably you see a better way to fix it.
> 1) Have a retval. In this case, we CopyBasicDataTo and return miByExt.
> 2) No retval. In this case we're hitting the SetMIMEType code already.
>
> So the patch only affects behavior in the case when we have both retval and
> miByExt. But all it changes is to call SetMIMEType instead of
> CopyBasicDataTo,
>
> Is CopyBasicDataTo clobbering the default app somehow in this case?
Not the default app but ...
Let me explain what currently happens using the special case this bug is about:
- type is application/
- ext is for example .pdf
- nsMIMEInfoBase* retval = GetFromType(
succeeds but has no default handler
- nsRefPtr<
GetFromExtens
succeeds and returns a valid mimeinfo containing even a default handler
-> now we call retval-
->
so it seems we end up with a mimeinfo which actually contains a default handler
but again uses type application/
That also means that every call to GetHasDefaultHa
Later in nsHelperAppDlg.js we handle application/
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #22 |
Ending up with a MIME info that has type application/
Sounds to me like that impl of GetHasDefaultHa
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #23 |
Created an attachment (id=334572)
another approach
That is a fix for nsMIMEInfoUnix:
(not familiar with nsRefPtr so I might be wrong with it)
But for that to actually offer the default application I had to change CopyBasicDataTo since it overwrites the default application after all.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #24 |
Created an attachment (id=334655)
Missing helper application error
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #25 |
I just applied your patches, and now I get an error, that the helper application for the file is missing. Tried it also on an image file, same problem on that one.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #26 |
(In reply to comment #25)
> I just applied your patches, and now I get an error, that the helper
> application for the file is missing. Tried it also on an image file, same
> problem on that one.
You only should use the "another approach" patch. Did you do that? I'm not sure how that would trigger your issue. And you get the error immediately when clicking on a download link?
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #27 |
> You only should use the "another approach" patch. Did you do that? I'm not sure
> how that would trigger your issue.
I installed the mozilla-
> And you get the error immediately when clicking on a download link?
No, when I klick on the testfile.pdf link, I do first get the download window, where the correct helper application is selected (haven't seen that before the patch). When I klick OK, the helper application (Acrobat Reader in this case) doesn't start and the error (screenshot) appears.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #28 |
Created an attachment (id=334886)
another approach #2
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #29 |
(From update of attachment 334886)
>--- uriloader/
>+++ uriloader/
>@@ -408,13 +408,13 @@ nsMIMEInfoBase:
> }
>
> void
> nsMIMEInfoBase:
> {
> aOther->mType = mType;
>- aOther-
>+ //aOther-
When it comes to gnome-vfs support overwriting mDefaultAppDesc
From looking at the code I'm not sure when it would make sense.
> NS_IMETHODIMP
> nsMIMEInfoUnix:
> {
> *_retval = PR_FALSE;
>- nsCOMPtr<
>- if (vfs) {
>- nsCOMPtr<
>- if (NS_SUCCEEDED(
>- *_retval = PR_TRUE;
>+ nsRefPtr<
>+ if (!mimeInfo) {
>+ nsCAutoString ext;
>+ if (NS_SUCCEEDED(
>+ mimeInfo = nsGNOMERegistry
I changed that to use nsGNOMERegistry since it's a bit shorter to implement.
I'm not sure why it was using the gnome-vfs component directly while the module already depends on nsGNOMERegistry but if there was a valid reason that could be changed.
> if (vfs) {
> nsCOMPtr<
> if (NS_SUCCEEDED(
> return app->Launch(
>+
>+ // If we haven't got an app we try to get a valid one by searching for the
>+ // extension mapped type
>+ nsRefPtr<
>+ if (mimeInfo) {
>+ nsCAutoString type;
>+ mimeInfo-
>+ if (NS_SUCCEEDED(
>+ return app->Launch(
>+ }
While commenting that part I actually think there should be a return value check for GetType()?
> // Copy the attributes of retval onto miByExt, to return it
> retval-
>+ // But set the extensions primary since CopyBasicDataTo overwrites the
>+ // list
>+ if (!aFileExt.
>+ retval-
This was actually a side effect by trying to fix the issue.
I _think_ that should be done but I might be wrong.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #30 |
So when can we expect to have it in the upstream release? The patch is working perfectly, and we need to have it the core!
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #31 |
(From update of attachment 334886)
biesi probably has no time.
The patch might not apply to mozilla-central anymore but I have an updated one but probably take some criticism before ;-)
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #32 |
What's the point of the CopyBasicDataTo change? The idea of that function is to copy whatever information you have, no? The header certainly documents it as copying that info. Look up why that was done originally? In any case, in your situation I can't see why removing this line is needed.
I'm not happy with the random object-creation stuff going on here. Why not change nsGNOMERegistry to expose functions to get a helper by type or extension and use them both in your new code and in the existing nsGNOMERegistry code?
Always setting the extension on the MIME info bothers me, though I can't figure out why. This is a situation where we got a MIME info for the MIME type, right? And the only issue was that this MIME info didn't have a default handler, which is why we fell back on getting one by extension? I guess we need to set the extension there to make the whole "get default app" thing work later...
Could we fix that by actually storing the default app in the MIMEInfo at construction time instead of messing around with hitting the GNOME registry every single time someone asks something of the MIME info? Or is there a major problem with that approach? I'm not sure why it wasn't taken here to start with.
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #33 |
(From update of attachment 334886)
r- pending answers to my questions.
In Mozilla Bugzilla #327323, A-sloman (a-sloman) wrote : | #34 |
(In reply to comment #8)
> Anyway there is a quick'n'dirty workaround to get a usable download UI back:
> Add for example the following line to your ~/.mailcap:
>
> application/
>
> By doing that the HelperAppService returns a default application (/bin/true)
> and the above constraints don't apply anymore. So you'll also get back the
> other alternatives returned by the MIMEInfo.
This works (for me) insofar as it provides a menu with the 'other' option, so that I can specify e.g. an editor to display the file. But it doesn't remember the editor. So, because my preferred editor is the poplog editor xved, I used the following in my .mailcap file:
application/
I can now click on the individual files in here and read them in the editor, whereas previously I had to download and read:
http://
I still have the 'other' menu option to use if necessary.
Thanks very much for the suggestion that led me to this.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #35 |
Created an attachment (id=396132)
updated patch
Updated to current mozilla-central and slightly changed to not change CopyBasicDataTo()
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #36 |
(In reply to comment #32)
> What's the point of the CopyBasicDataTo change? The idea of that function is
> to copy whatever information you have, no? The header certainly documents it
> as copying that info. Look up why that was done originally? In any case, in
> your situation I can't see why removing this line is needed.
The latest patch should explain why it's needed but I'm doing it differently now and not touching the cross platform method at all.
In written words: First we are getting a mimeinfo by type with no "default description" and because of that we try using the extension and get a valid result containing a default description. But afterwards we are overwriting the by-ext-mimeinfo with "basic" data in CopyBasicDataTo() including the empty default description. The new version of the patch sets the default description we just got also in the by-type-mimeinfo to preserve it after the copy.
> I'm not happy with the random object-creation stuff going on here. Why not
> change nsGNOMERegistry to expose functions to get a helper by type or extension
> and use them both in your new code and in the existing nsGNOMERegistry code?
I've read this a few times but I don't get what you are proposing in the end.
There are functions to get helpers by type or extension which are used.
Currently I have only changed the obvious code to use nsGNOMERegistry but also kept one use of nsIGnomeVFSService in LaunchDefaultWi
> Always setting the extension on the MIME info bothers me, though I can't figure
> out why. This is a situation where we got a MIME info for the MIME type,
> right? And the only issue was that this MIME info didn't have a default
> handler, which is why we fell back on getting one by extension? I guess we
> need to set the extension there to make the whole "get default app" thing work
> later...
My intention was to get a "valid" mimeinfo which "fits" the actual file.
> Could we fix that by actually storing the default app in the MIMEInfo at
> construction time instead of messing around with hitting the GNOME registry
> every single time someone asks something of the MIME info? Or is there a major
> problem with that approach? I'm not sure why it wasn't taken here to start
> with.
I don't really understand what you mean. My intention was to fix that bug (hopefully without introducing new ones) w/o much refactoring of the code. I'm happy to try to improve it further but I'm not that familiar with all of that code.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #37 |
So this bug is opened for 3 1/2 years, can we expect this somewhen in upstream releases!? 3.0.X is fixed on openSuSE repos, but the 3.5.X series is still broken. Thanks goes to Wolfgang Rosenauer for still contributing fixes to this bugzilla entry, but I really don't understand why Mozilla staff isn't willing to apply/work on this patch!
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #38 |
This patch is on my list of things to review. I estimate that it will take me several days of work to do so, since the code is underdocumented, fragile, and I haven't seriously looked at it in years. In case you missed it, the patch was posted a few weeks ago; I was away for two weeks of that time. Before that, there was a 7-month lag after my last round of review comments when nothing happened.
I _am_ hoping to get to this review in the next week.
If you want to help instead of just ranting, either take the higher-priority security bug work off my plate, or take some of the higher-priority reviews at http://
> but I really don't understand why Mozilla staff isn't willing to apply
The earlier versions weren't applied because they were wrong.
> work on this patch!
I'm not sure what you think "mozilla staff" is. This area of code is basically unowned; some Linux distro folks wrote it and then abandoned it. I really appreciate Wolfgang stepping up to work on it, and he's the closest to "mozilla staff" as far as this code is concerned.
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #39 |
>This patch is on my list of things to review. I estimate that it will take me several days of work to do so, since the code is underdocumented, fragile, and I haven't seriously looked at it in years.
I didn't know that the code isn't maintained!
>In case you missed it, the patch was posted a few weeks ago; I was away for two >weeks of that time. Before that, there was a 7-month lag after my last >round of >review comments when nothing happened.
The workaround in openSuSE repos from Wolfgang Rosenauer worked so far, so I didn't check in here as well.
>I _am_ hoping to get to this review in the next week.
Thats great to hear.
>If you want to help instead of just ranting, either take the higher-priority
security bug work off my plate, or take some of the higher-priority reviews at
http://
off my plate. If you can't do either of those, and can't help in some other
way that would free up some of my time (dealing with triage of incoming form
controls, docshell, and xbl bugs, profiling various pageload issues, writing
tests for the run-in section of the CSS2.1 specification, all come to mind as
low-barrier-
"I'm entitled to you not sleeping at night and instead reviewing this patch I
happen to care about" attitude comes from.
It's not on you Boris, I know that you're fully loaded with work. It was just a question if this will be ever fixed. You know, in our case were are using a webased groupware system, where nearly 95 % of the email attachments are recognized as application/
>I'm not sure what you think "mozilla staff" is. This area of code is basically
unowned; some Linux distro folks wrote it and then abandoned it. I really
appreciate Wolfgang stepping up to work on it, and he's the closest to "mozilla
staff" as far as this code is concerned.
Like I said, I didn't know that the code isn't maintained. "Mozilla staff" are the guys like you, who are working on the browser.
I really appreciate the work you do. I just wanted to know if the problems will be ever fixed, because I think 3 1/2 years is a real long time. Sorry for being a lil bit rude.
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #40 |
> I've read this a few times but I don't get what you are proposing in the end.
I think what I was proposing was that instead of using "can I get a MIME info object" as a proxy for "there is a default handler" we actually have a way to ask (probably the GNOME registry) "is there a handler for this type" and "is there a handler for this extension?"
I'm fine with this being a followup, I guess.
That might also be cheaper than creating the mime info objects, though I guess .hasDefaultHandler and .lanchDefaultWi
> I don't really understand what you mean.
I mean, just cache a boolean in the mimeinfo for whether it has a default handler and cache the app to use in LaunchDefaultWi
Wolfgang, what worries me about this setup is that if I send an application/pdf file with a .pl extension your browser will happily run it through a perl interpreter with this patch, right? And if a firewall was trying to enforce things based on MIME type, we lose.
Similarly, if I ask for the MIME info for a text/html file with a .cgi extension, and there is no default text/html handler but there _is_ a .cgi handler, we'll come back with a MIME info for text/html and extension .cgi. Not that likely, since we have default handlers for text/html, but if you have a CGI that produces types you do _not_ have default handlers for (e.g. word documents or C++ files or whatever) then this could well affect the "save as" codepath: see the getDefaultExtension function in contentAreaUtil
Johannes, if you want to help, can you help with testing this patch along the lines described above?
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #41 |
And to be clear, what I'm trying to avoid is a user trying to save a word document (say) and getting foo.doc.cgi as the suggested filename.
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #42 |
(In reply to comment #40)
> Wolfgang, what worries me about this setup is that if I send an application/pdf
> file with a .pl extension your browser will happily run it through a perl
> interpreter with this patch, right? And if a firewall was trying to enforce
> things based on MIME type, we lose.
if there is not default handler for application/pdf but we know one for *.pl that will be the case indeed.
I see the issue but what would be the better option? I.e. what is the desired behaviour?
Only fall back to the extension for application/
> Similarly, if I ask for the MIME info for a text/html file with a .cgi
> extension, and there is no default text/html handler but there _is_ a .cgi
> handler, we'll come back with a MIME info for text/html and extension .cgi.
> Not that likely, since we have default handlers for text/html, but if you have
> a CGI that produces types you do _not_ have default handlers for (e.g. word
> documents or C++ files or whatever) then this could well affect the "save as"
> codepath: see the getDefaultExtension function in contentAreaUtil
> Automated testing coverage for this stuff is spotty; what sort of manual
> testing has been done here?
Hmm, I haven't seen that issue with that patch but I don't think I've tried to actually trigger such a case.
The patch should still basically do the right thing without setting the primary extension though. I'll try to verify...
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #43 |
I actually tried to test the new patch myselfs:
1.) Downloaded and extractet he source "firefox-
2.) Applied the patch (updated patch (3.10 KB, patch)) :
patch -p1 < ../../../patch.diff
patching file uriloader/
Hunk #1 succeeded at 43 with fuzz 2 (offset -1 lines).
Hunk #3 succeeded at 110 with fuzz 2 (offset -4 lines).
patching file uriloader/
Hunk #1 succeeded at 1643 (offset 66 lines).
3.) configure with --enable-
When I know run firefox and try to open those application/
Did I do something wrong, or used the wrong source?
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #44 |
> I.e. what is the desired behaviour?
I would be tempted to consider only falling back for application/
> I'll try to verify...
That would be great.
> Did I do something wrong, or used the wrong source?
Seems like the right thing to me, pretty much... I assume you did make sure you ran your build, not whatever firefox happened to be installed on your system (and already running)?
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #45 |
Wolfgang, any luck on verifying per comment 42? Also, any idea what's going on in comment 33?
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #46 |
(In reply to comment #45)
> Wolfgang, any luck on verifying per comment 42?
I tried w/o setting the primary extension and I still get the default PDF viewer of the testcase in that bug.
I also talked to Johannes if he ever saw wrong extensions during his use and apparently he didn't. But the part of setting the primary extension was only a bonus and not mandatory to fix the issue.
> Also, any idea what's going on
> in comment 33?
You mean comment 43?
Not quite sure but I talked to Johannes about that also and he confirmed that my packages work for him iirc. Something with his compilation wasn't quite correct I assume.
I'll attach the current patch shortly for completeness but I only removed the SetPrimaryExtension call.
If you would feel a lot better I could also add the application/
In Mozilla Bugzilla #327323, Johannes-mueller-lahn (johannes-mueller-lahn) wrote : | #47 |
> I also talked to Johannes if he ever saw wrong extensions during his use and apparently he didn't.
Thats right. He never selected the wrong helper application. Tested the patch for a couple of month, and I can confirm that it's fixed 100 %.
> Not quite sure but I talked to Johannes about that also and he confirmed that
my packages work for him iirc. Something with his compilation wasn't quite
correct I assume.
I messed up with compiling from scratch. I tried it a couple of times, but I didn't succeed. Afterwars I use the openSuSE repos for Mozilla and installed the 3.5 series that are containg the patch from Wolfgang. The patch is also working perfectly like the ones from the default repos from openSuSE 11.0 (Firefox 3.0.X).
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #48 |
Wolfgang, looking forward to that current patch.
Also, can you push yourself, or should I just push the patch once it's reviewed?
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #49 |
Created an attachment (id=406796)
patch (mozilla-central)
Patch for mozilla-central w/o SetPrimaryExtension
(I have hg write access and can push it once it's done)
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #50 |
(From update of attachment 406796)
Let's try this!
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #51 |
In Mozilla Bugzilla #327323, Tyler Gates (tgates81) wrote : | #52 |
Does mozilla 1.9.3 mean this will be fixed in firefox 3.7? I have 3.5.8 and 3.5.1 and this is still a problem.
A long shot but does anyone have an up to date patch for 3.5.1? The latest provided here doesn't work and there have been quite a bit of changes to the code since then.
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #53 |
> Does mozilla 1.9.3 mean this will be fixed in firefox 3.7?
Yes.
In Mozilla Bugzilla #327323, Tyler Gates (tgates81) wrote : | #54 |
Does mozilla 1.9.3 mean this will be fixed in firefox 3.7? I have 3.5.8 and 3.5.1 and this is still a problem.
A long shot but does anyone have an up to date patch for 3.5.1? The latest provided here doesn't work and there have been quite a bit of changes to the code since then.
In Mozilla Bugzilla #327323, Tyler Gates (tgates81) wrote : | #55 |
Apologies for the double post.
In Mozilla Bugzilla #327323, Tyler Gates (tgates81) wrote : | #56 |
Created an attachment (id=442794)
nsMIMEInfoUnix.
A working patch to fix this issue in firefox 3.6.3
In Mozilla Bugzilla #327323, Tyler Gates (tgates81) wrote : | #57 |
Created an attachment (id=442796)
nsOSHelperAppSe
A working patch for this issue in firefox 3.6.3
Tyler Gates (tgates81) wrote : | #58 |
Binary package hint: firefox
There is currently a bug in firefox upstream where the "open with" dialog box will not appear for application links being sent as application/
https:/
See the "testdownload" link on the bug report page for an example of what I'm talking about:
https:/
Mozilla has acknowledged it is a problem (since 2006!) and will be fixed but that scheduled launch will be for mozilla 1.9.3, which is firefox 3.7.
I'm trying to get my organization migrated over to Ubuntu but this firefox bug in combination with needing to be able to handle several attachments from zimbra creates a problem. I've already patched their current firefox (3.6.3) with the following patches and it has been running solid for months now.
Below are links to the appropriate patches to make this work as it should (I guess I can't upload more than one patch at a time?). I would appreciate it if Ubuntu would please consider applying the patches to their firefox package so we can get this working as it should.
nsMMEInfoUnix.patch
https:/
nsOSHelperAppSe
https:/
Thank you,
Tyler
Tyler Gates (tgates81) wrote : | #59 |
Forgot to mention this is affected in Ubuntu 10.04 LTS.
Changed in firefox: | |
status: | Unknown → Fix Released |
In Mozilla Bugzilla #327323, Mfraser-teysbros (mfraser-teysbros) wrote : | #60 |
Running Firefox 3.5, I've added this line to ~/.mailcap
application/
In Mozilla Bugzilla #327323, Mfraser-teysbros (mfraser-teysbros) wrote : | #61 |
(In reply to comment #58)
> Running Firefox 3.5, I've added this line to ~/.mailcap
>
> application/
Also for a all-user fix, add the line to a file under /usr/lib/
Tyler Gates (tgates81) wrote : | #62 |
What is the status on this?
In Mozilla Bugzilla #327323, Ginn-chen (ginn-chen) wrote : | #63 |
*** Bug 464443 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #327323, Chris Coulson (chrisccoulson) wrote : | #64 |
Created attachment 471859
Patch for mozilla-1.9.2
Requesting for 1.9.2.10. This patch also indirectly fixes bug 455626, which I see a lot of people keep reporting in Ubuntu. Would be really nice to see that one fixed.
I had to drop the GIO parts for 1.9.2
In Mozilla Bugzilla #327323, Bzbarsky (bzbarsky) wrote : | #65 |
Comment on attachment 471859
Patch for mozilla-1.9.2
r=bzbarsky
Changed in firefox: | |
importance: | Unknown → Medium |
In Mozilla Bugzilla #327323, Dveditz (dveditz) wrote : | #66 |
Comment on attachment 471859
Patch for mozilla-1.9.2
Approved for 1.9.2.11, a=dveditz for release-drivers (although code-freeze for 1.9.2.11 is tomorrow, Sept 28)
In Mozilla Bugzilla #327323, Mozilla (mozilla) wrote : | #67 |
Changed in firefox: | |
milestone: | none → 3.6.11 |
Changed in firefox (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Triaged |
Chris Coulson (chrisccoulson) wrote : | #68 |
This is fixed in Maverick
Changed in firefox (Ubuntu): | |
status: | Triaged → Fix Released |
Tyler Gates (tgates81) wrote : | #69 |
Thanks Chris but why not Lucid to? I have an organization of 150+ machines using it and upgrading to Maverick just like that for firefox would not be ideal. I thought we were supposed to have continued support for on older systems for while?
I can continue to patch for Lucid but just curious why it is excluded in favor of Maverick.
Thanks,
Tyler
Chris Coulson (chrisccoulson) wrote : | #70 |
Bugs are always fixed in the development version first, and then we backport fixes to stable releases where appropriate, and after sufficient testing has been performed. See the SRU guidelines: https:/
Tyler Gates (tgates81) wrote : | #71 |
I see. Thank you for the clarification and tending to this bug.
Created an attachment (id=212006) octet-stream.
Image showing that I can only "Save to Disk", not "Open with" when a server sends a file as application/