Ubuntu
firefox package

user set middlemouse.contentLoadURL reset to Ubuntu default on fresh install

Bug #182187 reported by Mark Painter
10
Affects Status Importance Assigned to Milestone
firefox (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: firefox

On two separate installs of Hardy where /home is preserved, I've had the preference middlemouse.contentLoadURL reset to Ubuntu's default. Fortunately, after I toggle it back to true, it stays where I set it.

Revision history for this message
Alexander Sack (asac) wrote :

Hi,

please resubmit your bug report using the firefox Help -> Report a Problem menu entry. This will gather additonal valuable information we need to look into this.

Thanks,
 - Alexander

Changed in firefox:
status: New → Invalid
Revision history for this message
Tollef Fog Heen (tfheen) wrote :

I see this on each and every new upstream revision. It doesn't seem like it is triggered when there's just a new Ubuntu revision, but every time I get the "checking for compatibility with existing extensions" window, it seems like middlemouse.contentLoadURL is reset.

Changed in firefox:
status: Invalid → Confirmed
Revision history for this message
Adrian Bridgett (adrian-bridgett) wrote :

this is a really infuriating bug - are we anywhere nearer getting it fixed? FWIW I've not seen this on my Debian (sid) desktop

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 182187] Re: user set middlemouse.contentLoadURL reset to Ubuntu default on fresh install

On Mon, Jun 09, 2008 at 09:53:02AM -0000, Adrian Bridgett wrote:
> this is a really infuriating bug - are we anywhere nearer getting it
> fixed? FWIW I've not seen this on my Debian (sid) desktop
>

Where do you see this? in gutsy it should be fixed. in hardy too
afaict.

Let us know.

 - Alexander

Revision history for this message
Adrian Bridgett (adrian-bridgett) wrote :

I see it in Hardy (quite frequently). I've just added it into my user.js (IIRC - I'm on another box ATM) to force it. I started to do as you said about using the submit bug way but I couldn't see a way to grab the details (or search accurately enough for it to find this report (I think as it was associating it with "firefox-3.0" not "firefox".

Revision history for this message
Michael Crozier (crozierm) wrote :

This exists in Karmic too. It's infuriating.

Revision history for this message
Harald Hannelius (harald-arcada) wrote :

This exists in oneirici too. It's infuriating.

Revision history for this message
Paul White (paulw2u) wrote :

We are sorry that we do not always have the capacity to review all reported bugs in a timely manner. This bug was reported a long time ago and there have been many changes in Ubuntu and Firefox since that time.

Does anyone still see a problem related to the one that was reported using currently supported versions of Firefox and Ubuntu? Please let us know if you do and in which version of Ubuntu otherwise this report can be left to expire in approximately 60 days time.

Thank you for helping make Ubuntu better.

Paul White
[Ubuntu Bug Squad]

Changed in firefox (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for firefox (Ubuntu) because there has been no activity for 60 days.]

Changed in firefox (Ubuntu):
status: Incomplete → Expired
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.