Ubuntu
firefox-3.0 package

Firefox3 does not remember application association

Bug #243704 reported by f3a97
10
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox-3.0 (Ubuntu)
Won't Fix
Medium
Unassigned
firefox-3.5 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: firefox-3.0

Hi,
     using the great Firefox3, I've noticed that a buggy behaviour that was present in Firefox2 is still occuring.

In a nutshell, what happens to me is that firefox does not always remember the application association that has been previously set.

For example, during web surfing I open a WMV video, and I choose to play it with the Totem plugin. I obviously check the option to remember this association.

Now, in the beginning the videos are correctly played with Totem plugin. After some time, though, Firefox keeps asking me which application to used to open those files. If I go to the Application section of Firefox preferences, I FIND the entry that associate WMV -> Totem plugin - but it seems that it is taken into consideration by firefox.

Note: the "open with" popup windows has the remember option already checked, when it comes up. As I said early, I've experimented this issue also with firefox 2.0.

Let me know if I can help to track down this issue. I'm using Hardy up-to-date as of now.

ste@ste-ubuntu:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

ste@ste-ubuntu:~$ apt-cache policy firefox
firefox:
  Installed: 3.0+nobinonly-0ubuntu0.8.04.1
  Candidate: 3.0+nobinonly-0ubuntu0.8.04.1
  Version table:
 *** 3.0+nobinonly-0ubuntu0.8.04.1 0
        500 http://sm.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     3.0~b5+nobinonly-0ubuntu3 0
        500 http://sm.archive.ubuntu.com hardy/main Packages

See original description
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 326043
patch

Replacing system() with nsIProcess seems to fix the issue.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Comment on attachment 326043
patch

Maybe the last if should read if (NS_SUCCEEDED(process->Run(PR_TRUE, args, 2, NULL))) ?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Comment on attachment 326043
patch

>+ LOG(("Running Test: %s %d\n", testCommand.get(), rv));

'rv' should always be success here, right? Why log it?

Put single quotes around the %s in the string to make it easy to tell where it starts/ends?

>+ if (process->Run(PR_TRUE, args, 2, NULL)) {

Uh... have you tested this? Using what tests?

Is passing null for the out param even legal? I wouldn't have thought so, given typical IDL contracts... Also, does Run() really throw if the process exits with a nonzero error code? Or should you be looking at process->GetExitValue()?

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to comment #3)
> (From update of attachment 326043 [details])
> >+ LOG(("Running Test: %s %d\n", testCommand.get(), rv));
>
> 'rv' should always be success here, right? Why log it?

That is a shameful piece left from debugging...

> Put single quotes around the %s in the string to make it easy to tell where it
> starts/ends?
>
> >+ if (process->Run(PR_TRUE, args, 2, NULL)) {
>
> Uh... have you tested this? Using what tests?
>
> Is passing null for the out param even legal? I wouldn't have thought so,
> given typical IDL contracts...

Actually, the function does nothing with the argument... it doesn't return a pid. But I agree it doesn't hurt to replace it.

> Also, does Run() really throw if the process
> exits with a nonzero error code? Or should you be looking at
> process->GetExitValue()?

Looking more closely to the code, you are right. I shouldn't write such patches late in the night.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

> Actually, the function does nothing with the argument... it doesn't return a
> pid. But I agree it doesn't hurt to replace it.

Thinking more about it, even if pid was set in Run(), it shouldn't be set in the blocking case.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Logically, yes. But the IDL signature is such that passing in NULL means the callee would be perfectly within its rights to crash. So we shouldn't do that.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 326100
patch v2

What about this ?

Revision history for this message
f3a97 (f3a97) wrote :

Binary package hint: firefox-3.0

Hi,
     using the great Firefox3, I've noticed that a buggy behaviour that was present in Firefox2 is still occuring.

In a nutshell, what happens to me is that firefox does not always remember the application association that has been previously set.

For example, during web surfing I open a WMV video, and I choose to play it with the Totem plugin. I obviously check the option to remember this association.

Now, in the beginning the videos are correctly played with Totem plugin. After some time, though, Firefox keeps asking me which application to used to open those files. If I go to the Application section of Firefox preferences, I FIND the entry that associate WMV -> Totem plugin - but it seems that it is taken into consideration by firefox.

Note: the "open with" popup windows has the remember option already checked, when it comes up. As I said early, I've experimented this issue also with firefox 2.0.

Let me know if I can help to track down this issue. I'm using Hardy up-to-date as of now.

ste@ste-ubuntu:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

ste@ste-ubuntu:~$ apt-cache policy firefox
firefox:
  Installed: 3.0+nobinonly-0ubuntu0.8.04.1
  Candidate: 3.0+nobinonly-0ubuntu0.8.04.1
  Version table:
 *** 3.0+nobinonly-0ubuntu0.8.04.1 0
        500 http://sm.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     3.0~b5+nobinonly-0ubuntu3 0
        500 http://sm.archive.ubuntu.com hardy/main Packages

Revision history for this message
f3a97 (f3a97) wrote :

As Alexander Sack pointed out to me,
      this is probably due to this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=440840

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Comment on attachment 326100
patch v2

>+ if (NS_FAILED(rv = process->Init(file)))

Break this up into two lines, please?

>+ process->GetExitValue(&exitValue);

Check the rv of this?

With those two changes, r=bzbarsky

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 329193
patch v3

Here you are

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 329194
patch v3.0.1

That was the wrong one

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Comment on attachment 329194
patch v3.0.1

Looks great

Revision history for this message
In , Reed Loden (reed) wrote :

Pushed as 15839:3268e0025bba.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Fix Released
Revision history for this message
f3a97 (f3a97) wrote :

Upstream this bug is marked as "RESOLVED FIXED".

In which release of firefox I may ask?

Currently I'm testing asac PPA of firefox 3.0.1, and the bug is still there.

ste@ste-ubuntu:~$ apt-cache policy firefox
firefox:
  Installed: 3.0.1+build1+nobinonly-0ubuntu0.8.04.1~ppa1
  Candidate: 3.0.1+build1+nobinonly-0ubuntu0.8.04.1~ppa1
  Version table:
 *** 3.0.1+build1+nobinonly-0ubuntu0.8.04.1~ppa1 0
        500 http://ppa.launchpad.net hardy/main Packages
        100 /var/lib/dpkg/status
     3.0+nobinonly-0ubuntu0.8.04.1 0
        500 http://sm.archive.ubuntu.com hardy-updates/main Packages
     3.0~b5+nobinonly-0ubuntu3 0
        500 http://sm.archive.ubuntu.com hardy/main Packages

Revision history for this message
Robert (rcdailey) wrote :

Hi, I just wanted to mention that I'm seeing this issue as well. The program I'm trying to bind is C:\altbinz\altbinz.exe, and I map it to NZB files. I'm using Firefox 3.0.1. Are there any plans to fix this bug? It's rather annoying.

Revision history for this message
In , Samuel-sidler+old (samuel-sidler+old) wrote :

I'm not clear of the risk of this patch. There's no test for it (automated or otherwise). Is there any way we can get one before approving for 1.9.0.2? What's the advantage to taking it vs waiting for 1.9.1?

(Reed should know better than to request approval on a patch with no info about it...)

Revision history for this message
f3a97 (f3a97) wrote :

Guys,
     I can confirm that the problem is still there.

Upstream bug says RESOLVED FIXED, do we have that patch in Ubuntu?

ste@ste-ubuntu:~$ apt-cache policy firefox
firefox:
  Installed: 3.0.1+build1+nobinonly-0ubuntu0.8.04.3
  Candidate: 3.0.1+build1+nobinonly-0ubuntu0.8.04.3
  Version table:
 *** 3.0.1+build1+nobinonly-0ubuntu0.8.04.3 0
        500 http://sm.archive.ubuntu.com hardy-updates/main Packages
        500 http://security.ubuntu.com hardy-security/main Packages
        100 /var/lib/dpkg/status
     3.0~b5+nobinonly-0ubuntu3 0
        500 http://sm.archive.ubuntu.com hardy/main Packages

Thanks

Revision history for this message
In , Samuel-sidler+old (samuel-sidler+old) wrote :

Comment on attachment 329194
patch v3.0.1

Clearing approval request until comment 13 is addressed.

Revision history for this message
bartek (fubard) wrote :

Bug still definitely there. My build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

Revision history for this message
f3a97 (f3a97) wrote :

Hi,
   are there any plan to fix this?

It is still there, hardy up to date, firefox 3.0.3.

Thanks!

Revision history for this message
sciasbat (fabio-forno) wrote :

Bug still present in intrepid (and apparently much more frequent and annoying)

Revision history for this message
f3a97 (f3a97) wrote : Re: [Bug 243704] Re: Firefox3 does not remember application association

Yeah,
   I definitely confirm that!

It's pretty annoying in fact.

Let us know how we can help to track this down.

2008/11/13 sciasbat <email address hidden>

> Bug still present in intrepid (and apparently much more frequent and
> annoying)
>
> --
> Firefox3 does not remember application association
> https://bugs.launchpad.net/bugs/243704
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Mozilla Firefox Browser: Fix Released
> Status in "firefox-3.0" source package in Ubuntu: New
>
> Bug description:
> Binary package hint: firefox-3.0
>
> Hi,
> using the great Firefox3, I've noticed that a buggy behaviour that was
> present in Firefox2 is still occuring.
>
> In a nutshell, what happens to me is that firefox does not always remember
> the application association that has been previously set.
>
> For example, during web surfing I open a WMV video, and I choose to play it
> with the Totem plugin. I obviously check the option to remember this
> association.
>
> Now, in the beginning the videos are correctly played with Totem plugin.
> After some time, though, Firefox keeps asking me which application to used
> to open those files. If I go to the Application section of Firefox
> preferences, I FIND the entry that associate WMV -> Totem plugin - but it
> seems that it is taken into consideration by firefox.
>
> Note: the "open with" popup windows has the remember option already
> checked, when it comes up. As I said early, I've experimented this issue
> also with firefox 2.0.
>
> Let me know if I can help to track down this issue. I'm using Hardy
> up-to-date as of now.
>
> ste@ste-ubuntu:~$ lsb_release -rd
> Description: Ubuntu 8.04
> Release: 8.04
>
> ste@ste-ubuntu:~$ apt-cache policy firefox
> firefox:
> Installed: 3.0+nobinonly-0ubuntu0.8.04.1
> Candidate: 3.0+nobinonly-0ubuntu0.8.04.1
> Version table:
> *** 3.0+nobinonly-0ubuntu0.8.04.1 0
> 500 http://sm.archive.ubuntu.com hardy-updates/main Packages
> 100 /var/lib/dpkg/status
> 3.0~b5+nobinonly-0ubuntu3 0
> 500 http://sm.archive.ubuntu.com hardy/main Packages
>

Revision history for this message
In , eel ghEEz (ilatypov) wrote :

I see the same failure to remember associations in 3.1b3pre (nightly build of Firefox, Shiretoko for Windows).

Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

This is fixed upstream now.

Changed in firefox-3.0:
status: New → Fix Committed
Revision history for this message
Micah Gersten (micahg) wrote :

This was fixed with the initial release of Firefox 3.5

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.

Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Fix Committed → Won't Fix
Revision history for this message
Hiker Hauk (hhauk) wrote :

9.10 fresh install and updated, Firefox 3.5.3, still happens.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.