Ubuntu
firefox package

forgets middlemouse.contentLoadURL on upgrade or browser restart

Bug #548866 reported by Kees Cook
222
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Expired
Medium
firefox (Ubuntu)
Triaged
Low
Unassigned
Lucid
Fix Released
Low
Unassigned
Maverick
Fix Released
Low
Unassigned
Precise
Won't Fix
Low
Unassigned

Bug Description

Binary package hint: firefox

Whenever firefox is updated, the setting for middlemouse.contentLoadURL is forgotten in my profiles.

To simulate this:

0) go to "about:config" and set middlemouse.contentLoadURL to "true"
1) close firefox
2) remove .mozilla/firefox/[profile]/compatibility.ini
3) open firefox
4) observe setting has reverted to "false"

See original description
Revision history for this message
In , Alexander Sack (asac) wrote :

Created an attachment (id=351173)
for 1.9.1

ubuntu xulrunner-1.9.1 patch.

Revision history for this message
In , Mike Connor (mconnor) wrote :

(From update of attachment 351173)
also punting this to bsmedberg (keeping a running tally, now up to 3)

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

so, this will fail for this case:

system: pref = 1
ext_a1: pref = 2

user: pref = 1

user upgrades and ext_a1 is incompatible w/ firefox

system: pref = 1
user: pref = 1

user quits.

pref is lost.

later, user runs the browser and installs ext_a2 (upgraded extension ext_a version 2, which is compatible w/ the upgrade) and gets:
ext_a2: pref = 2

I think to handle this case, you'd need to scan All extensions, enabled and disabled. for any pref which exists in multiple locations set a flag "don't wipe". and when you quit, only wipe prefs if they aren't tagged "don't wipe".

it's probably also ok to maintain a file in the profile dir listing prefs which shouldn't be wiped, they can use the same logic, it should be append only, that'd save you the trouble of scanning disabled things.

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

I wonder if we really want this automagic reset of user prefs at shutdown at all ... why not keep them as user prefs unless you explicitly say "reset" (either in about:config or through API) ... for me it seems that if a user ever explicitly selected a specific pref you hardly ever want to go back to ride the default again. Thoughts?

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

I've wanted to remove the feature for 8+ years.

I think we should probably remove the feature, and have someone write an extension similar to regclean/regmaid
http://support.microsoft.com/default.aspx/kb/299958
http://support.microsoft.com/kb/156078

our extension should basically tell users when a preference name/value became obsolete and let them choose to remove it. RegMaid is the advanced version of RegClean - RegClean or a mozilla equivalent would merely create a backup of the removed prefs and remove all prefs which don't make sense to the current run. It should warn the user about any prefs which are for extensions which aren't enabled.

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

(In reply to comment #5)
> I've wanted to remove the feature for 8+ years.
>

Do you have any references for previous discussions? I would like to read the arguments before actually complaining ;).

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

finding them would take more effort than i'm willing to expend, they could be in irc logs (which would entail finding someone w/ logs from the right period), or one of a number of mailboxes (this should cover bugzilla), or newsgroups.

one instance for this was switching a profile between netscape 6 and mozilla where they differed on a pref value.... but the problem is older so i'm not sure when it would have been discussed. alecf might remember it, although i'm sure he'd rather forget, possibly bnesse....

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

bug 58326 is perhaps one of the older bugs on the subject.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

(From update of attachment 351173)
I cannot accept this without a test (probably several tests, given its nature)

Revision history for this message
Kees Cook (kees) wrote : forgets middlemouse.contentLoadURL on upgrade

Binary package hint: firefox

Whenever firefox is updated, the setting for middlemouse.contentLoadURL is forgotten in my profiles.

To simulate this:

0) go to "about:config" and set middlemouse.contentLoadURL to "true"
1) close firefox
2) remove .mozilla/firefox/[profile]/compatibility.ini
3) open firefox
4) observe setting has reverted to "false"

Micah Gersten (micahg)
Changed in firefox (Ubuntu Lucid):
assignee: nobody → Micah Gersten (micahg)
importance: Undecided → Low
milestone: none → ubuntu-10.04-beta-2
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → In Progress
Revision history for this message
Micah Gersten (micahg) wrote :

bzr commit -m '* fix LP: #548866 - forgets middlemouse.contentLoadURL on upgrade; add patch
  from xulrunner-1.9.1
  - update debian/patches/series
  - add debian/patches/lp548866_bz467766_att351173-dont-reset-user-prefs-on-upgrade.patch'

Changed in firefox (Ubuntu Lucid):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 3.6.3+nobinonly-0ubuntu1

---------------
firefox (3.6.3+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6.3 (FIREFOX_3_6_3_RELEASE)

  [ Jamie Strandboge <email address hidden> ]
  * AppArmor:
    - add leafpad and mousepad text editors for XFCE users (LP: #543587)

  [ Micah Gersten <email address hidden> ]
  * fix LP: #548866 - forgets middlemouse.contentLoadURL on upgrade; add patch
    from xulrunner-1.9.1
    - update debian/patches/series
    - add debian/patches/lp548866_bz467766_att351173-dont-reset-user-prefs-on-upgrade.patch

  [ Chris Coulson <email address hidden> ]
  * Add a cairo LCD filter to use Freetype LCD colour filtering features,
    based on the same patch applied to our system cairo package. Thanks to
    Marc Deslauriers for helping to make this work. (LP: #512615)
    - add debian/patches/lp512615_cairo_lcd_filter.patch
    - update debian/patches/series
  * Fix LP: #546490 - "Firefox will not start in debug mode"
    - update debian/firefox.sh.in
  * Fix a build issue installing ubuntu-abrowser.js when building with
    DEB_MIN_SYSDEPS=0
    - update debian/rules
 -- Chris Coulson <email address hidden> Fri, 02 Apr 2010 16:44:02 +0100

Changed in firefox (Ubuntu Lucid):
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Note, that the fix for this bug is causing bug 643899 now that we have Sync in Natty, as it changes the way that the public preferences API works.

Note that the intl.accept_languages pref is set to "chrome://global/locale/intl.properties", which means that if you do nsIPrefBranch.getComplexValue() on that pref (which is how the network code sets the accept-language header), it will return a string containing a list of languages from the specified chrome file (and this chrome file is shipped in our language packs).

Firefox sync in Natty is synchronizing preferences, with intl.accept_languages being on the whitelist. (Note, that it syncs the value "chrome://global/locale/intl.properties" between nodes). When a node receives this preference, it does nsIPrefBranch.setComplexValue(). On a default mozilla.org build of Firefox where the user hasn't changed this preference, this action is benign (because it discards user prefs when they equal the default system-pref setting). However, on Ubuntu, this actually saves "chrome://global/locale/intl.properties" as a user pref. Unfortunately, user-prefs don't support localization (they don't need to), so a subsequent call to nsIPrefBranch.getComplexValue from the network code returns "chrome://global/locale/intl.properties" rather than a nice list of languages (eg, "en-us, en").

This is a pretty serious bug for Natty users - it's breaking essential websites such as most Google sites (and is also visible to Mozilla). I think we're going to have to regress this to fix bug 643899 unfortunately....

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Note, even worse than that, calling nsIPrefBranch.setComplexValue() with a value equal to the system default has a different result depending on if there is a user preference or not. If there is a user pref, it clears it. If there isn't a user pref, then it adds one. Eeek. I'm afraid we need to drop this patch until we think of a nicer way to fix it :/

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted firefox into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in firefox (Ubuntu Natty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote : Re: forgets middlemouse.contentLoadURL on upgrade

Please ignore the previous comment.

tags: removed: verification-needed
Changed in firefox (Ubuntu Natty):
status: Fix Committed → Triaged
Chris Coulson (chrisccoulson)
tags: added: regression-update
Changed in firefox (Ubuntu Natty):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 4.0.1+build1+nobinonly-0ubuntu0.11.04.2

---------------
firefox (4.0.1+build1+nobinonly-0ubuntu0.11.04.2) natty-proposed; urgency=low

  * Fix LP: #770719 - Dutch localization doesn't include spell-checker.
    Look in /usr/share/hunspell for the system dictionaries on maverick
    and later, rather than /usr/share/myspell/dicts. This got dropped
    somehow in natty
    - update debian/rules
    - update debian/firefox.links/in
  * Hopefully fix LP: #643899 - Firefox sending header "Accept-Language:
    chrome://global/locale/intl.properties" because the intl.accept_languages
    preference is messed up. Drop a patch which causes the preferences
    system to save a user preference when changing a preference value to equal
    the system default value (and revert to the original behaviour where the
    preference is just discarded). This should hopefully stop Firefox Sync
    from breaking localized preferences where they haven't been modified by
    the user, but does regress LP: #548866
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Tue, 03 May 2011 20:43:30 +0100

Changed in firefox (Ubuntu Natty):
status: Triaged → Fix Released
Chris Coulson (chrisccoulson)
Changed in firefox (Ubuntu Natty):
status: Fix Released → Triaged
Changed in firefox (Ubuntu):
status: Fix Released → Triaged
Revision history for this message
Migrus (migrus123) wrote :

The description/title of this only speaks of this happening on update. I am getting this on every restart of the browser (as described in Bug #784542, which was set as a duplicate of this). Perhaps the title of this report should be changed to say restart?

I think from comment 17 that this is known to be on restart and not on upgrade. But to make sure there is no misunderstanding, here are the steps I take to reproduce this:

1. Start firefox, enter about:config, set middlemouse.contentLoadURL to true
2. middlemouse-paste a URL to a window, it loads the URL ()
3. Stop firefox, check the 'prefs.js' file:
 $ grep middle prefs.js
 user_pref("middlemouse.contentLoadURL", true);
4. Start firefox, the setting is gone from the about:config and the
   'prefs.js' file:
 $ grep middle prefs.js
 $
5. middlemouse-paste a URL to a window, it does nothing.

I can get this working by disabling the "Ubuntu Firefox Modifications" add-on.

Not sure why that did not work for the reporter of Bug #784542. Possibly that some other setting is in conflict? I normally disable:
browser.tabs.opentabfor.middleclick
middlemouse.openNewWindow

Revision history for this message
Torsten Bronger (bronger) wrote :

I experience the same erroneous behaviour as Migrus, and his workaround works also for me. I am not sure when this started though. At least, it was not immediately after the upgrade to Natty.

Bryce Harrington (bryce)
summary: - forgets middlemouse.contentLoadURL on upgrade
+ forgets middlemouse.contentLoadURL on upgrade or browser restart
Revision history for this message
Kees Cook (kees) wrote :

For the impatient, I've created a Firefox Extension that forces middlemouse.contentLoadURL to true:
http://outflux.net/software/pkgs/thewolf/

Revision history for this message
sasha (sashalav) wrote :

Thanks Kees, nice and simple.

Revision history for this message
John McPherson (john-mcpherson) wrote :

This setting is hard-coded in the Ubuntu Firefox Modifications add-on:

  $ grep middlemouse /usr/share/xul-ext/ubufox/defaults/preferences/ubuntu-mods.js
  pref("middlemouse.contentLoadURL", false); // setting to false disables pasting urls on to the page

This overrides any user-specified setting saved in .mozilla/firefox/[profile]/prefs.js, but also overrides any setting stored in user.js even though user.js is supposed to take precedence.

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Also note that saving a user pref when it is equal to the default pref breaks with Firefox Sync and complex prefs (see https://launchpad.net/bugs/643899)

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

This bug is still present in OneIRIC, and it's very annoying.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (18.4 KiB)

This bug was fixed in the package firefox - 9.0.1+build1-0ubuntu0.10.10.2

---------------
firefox (9.0.1+build1-0ubuntu0.10.10.2) maverick-proposed; urgency=low

  [ Chris Coulson <email address hidden> ]
  * Fix LP: #907666 - readd missing kubuntu-firefox-installer Replaces
    - update debian/control

  [ Micah Gersten <email address hidden> ]
  * Fix LP: #917529 - Make sure new transitional packages have a versioned
    dependency on Firefox so as to not break Firefox during partial upgrades
    - update debian/control{,.in}

firefox (9.0.1+build1-0ubuntu0.10.10.1) maverick-proposed; urgency=low

  * New upstream stable release (FIREFOX_9_0_1_BUILD1) (LP: #904594)

firefox (9.0+build1-0ubuntu0.10.10.1) maverick-proposed; urgency=low

  * New upstream stable release (FIREFOX_9_0_BUILD1)

  [ Chris Coulson <email address hidden> ]
  * Install the Apport hook as a source package hook
    - rename debian/apport/firefox.py.in => debian/apport/source_firefox.py.in
    - update debian/firefox.install.in
    - update debian/rules
  * Don't unconditionally overwrite SourcePackage when reporting bugs with
    the nightly apport hook
    - update debian/apport/source_firefox.py.in
  * Set "Channel = Unavailable" if channel-prefs.js doesn't contain a
    channel name
    - update debian/apport/source_firefox.py.in
  * Ensure that create-tarball can handle there not being a locale blacklist
    - update debian/build/create-tarball.py
  * Drop xpt.py and xpidl from $LIBDIR. xpidl is gone, and xpt.py isn't included
    there in the upstream SDK
    - update debian/firefox-dev.links.in
  * Fix LP: #901838 - Ugly busy pointer, due to libxcursor no longer matching
    the cursor bitmap to a nice themed pointer
    - add debian/patches/fix-cursor-handling.patch
    - update debian/patches/series
  * Don't disable our bundled addons on upgrade
    - update debian/vendor.js
  * Modify the UA string to add "Ubuntu" to the platform component
    - add debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/series
    - update debian/rules
  * Move custom scripts to debian/build
    - move debian/get-xpi-id.py to debian/build/get-xpi-id.py
    - move debian/refresh-supported-locales.pl to
       debian/build/refresh-supported-locales.pl
    - move debian/extract-file.py to debian/build/extract-file.py
    - update debian/rules
    - move debian/testsuite.mk to debian/build/testsuite.mk
  * Dropped patches that are obsolete or fixed upstream:
    - remove debian/patches/lp512615_cairo_lcd_filter.patch
    - remove debian/patches/lp185622_system_path_default_browser.patch
    - remove debian/patches/bz386904_config_rules_install_dist_files.patch
    - remove debian/patches/bz532198_lp488354_ns_invokebyindex_not_thumb2_safe.patch
    - remove debian/patches/bzXXX_libxul_sdk_nspr.patch
    - remove debian/patches/drop_bz418016.patch
    - remove debian/patches/firefox-fsh
    - remove debian/patches/firefox-profilename
    - remove debian/patches/ubuntu_no_app_updates.patch
    - update debian/patches/series
  * Refresh patches:
    - update debian/patches/firefox-kde.patch
    - update debian/patches/mozilla-kde.patch
    - update debia...

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Sorry, this was regressed in the recent Firefox 9 update.

Changed in firefox (Ubuntu Lucid):
milestone: ubuntu-10.04-beta-2 → none
status: Fix Released → Triaged
Micah Gersten (micahg)
Changed in firefox (Ubuntu Lucid):
assignee: Micah Gersten (micahg) → nobody
Changed in firefox (Ubuntu Precise):
status: Fix Released → Triaged
assignee: Micah Gersten (micahg) → nobody
milestone: ubuntu-10.04-beta-2 → none
Changed in firefox (Ubuntu Oneiric):
status: New → Triaged
Changed in firefox (Ubuntu Maverick):
status: New → Triaged
importance: Undecided → Low
Changed in firefox (Ubuntu Oneiric):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (18.2 KiB)

This bug was fixed in the package firefox - 9.0.1+build1-0ubuntu0.10.04.2

---------------
firefox (9.0.1+build1-0ubuntu0.10.04.2) lucid-proposed; urgency=low

  [ Chris Coulson <email address hidden> ]
  * Fix LP: #907666 - readd missing kubuntu-firefox-installer Replaces
    - update debian/control

  [ Micah Gersten <email address hidden> ]
  * Fix LP: #917529 - Make sure new transitional packages have a versioned
    dependency on Firefox so as to not break Firefox during partial upgrades
    - update debian/control{,.in}

firefox (9.0.1+build1-0ubuntu0.10.04.1) lucid-proposed; urgency=low

  * New upstream stable release (FIREFOX_9_0_1_BUILD1) (LP: #904594)

firefox (9.0+build1-0ubuntu0.10.04.1) lucid-proposed; urgency=low

  * New upstream stable release (FIREFOX_9_0_BUILD1)

  [ Chris Coulson <email address hidden> ]
  * Install the Apport hook as a source package hook
    - rename debian/apport/firefox.py.in => debian/apport/source_firefox.py.in
    - update debian/firefox.install.in
    - update debian/rules
  * Don't unconditionally overwrite SourcePackage when reporting bugs with
    the nightly apport hook
    - update debian/apport/source_firefox.py.in
  * Set "Channel = Unavailable" if channel-prefs.js doesn't contain a
    channel name
    - update debian/apport/source_firefox.py.in
  * Ensure that create-tarball can handle there not being a locale blacklist
    - update debian/build/create-tarball.py
  * Drop xpt.py and xpidl from $LIBDIR. xpidl is gone, and xpt.py isn't included
    there in the upstream SDK
    - update debian/firefox-dev.links.in
  * Fix LP: #901838 - Ugly busy pointer, due to libxcursor no longer matching
    the cursor bitmap to a nice themed pointer
    - add debian/patches/fix-cursor-handling.patch
    - update debian/patches/series
  * Don't disable our bundled addons on upgrade
    - update debian/vendor.js
  * Modify the UA string to add "Ubuntu" to the platform component
    - add debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/series
    - update debian/rules
  * Move custom scripts to debian/build
    - move debian/get-xpi-id.py to debian/build/get-xpi-id.py
    - move debian/refresh-supported-locales.pl to
       debian/build/refresh-supported-locales.pl
    - move debian/extract-file.py to debian/build/extract-file.py
    - update debian/rules
    - move debian/testsuite.mk to debian/build/testsuite.mk
  * Dropped patches that are obsolete or fixed upstream:
    - remove debian/patches/lp512615_cairo_lcd_filter.patch
    - remove debian/patches/lp185622_system_path_default_browser.patch
    - remove debian/patches/bz386904_config_rules_install_dist_files.patch
    - remove debian/patches/bz532198_lp488354_ns_invokebyindex_not_thumb2_safe.patch
    - remove debian/patches/bzXXX_libxul_sdk_nspr.patch
    - remove debian/patches/drop_bz418016.patch
    - remove debian/patches/firefox-fsh
    - remove debian/patches/firefox-profilename
    - remove debian/patches/ubuntu_no_app_updates.patch
    - update debian/patches/series
  * Refresh patches:
    - update debian/patches/firefox-kde.patch
    - update debian/patches/mozilla-kde.patch
    - update debian/patches...

Changed in firefox (Ubuntu Lucid):
status: Triaged → Fix Released
Revision history for this message
Martin Pohlack (mp26+launch) wrote :

I am too having this bug on natty with 9.0.1+build1-0ubuntu0.11.04.1

I must say that I get a very unrespectful impression of the behaviour of the package. User settings should be holy and never be touched / corrupted.

Is uninstalling the ubuntu-support package for firefox a fix here?

Revision history for this message
Alex Selby (launchpad-archduke) wrote :

I am still experiencing this bug on Lucid. I am using firefox 9.0.1+build1-0ubuntu0.10.04.2, which is the same version as in Launchpad Janitor's post above, so I can't agree that this should be classified as "Fix Released".

Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 548866] Re: forgets middlemouse.contentLoadURL on upgrade or browser restart

Excerpts from Alex Selby's message of Fri Feb 03 13:01:16 UTC 2012:
> I am still experiencing this bug on Lucid. I am using firefox
> 9.0.1+build1-0ubuntu0.10.04.2, which is the same version as in Launchpad
> Janitor's post above, so I can't agree that this should be classified as
> "Fix Released".
>

Alex, if you believe that the bug has returned, you should open a new
bug report, and reference it as a regression of this bug. This will
help us to track it properly and give us the extra information we need
to reproduce the regression. Run 'ubuntu-bug firefox' and apport will
collect information from your system that will help us identify the issue.

Please once you've done that come back to this bug report and post a
comment to the new one so we can find it faster.

Thanks!

Revision history for this message
Alex Selby (launchpad-archduke) wrote :

Hi Clint, thanks for the reply. I think that either I have made a mistake and the bug is really fixed, or reply #27 is mistaken and the bug was not fixed by the update.

Perhaps the problem is that I have somehow not installed the update. The output of "dpkg -l firefox" shows 9.0.1+build1-0ubuntu0.10.04.2, but perhaps that is not sufficient to ensure that it is the same as the update specified in message #27. I don't really know much about this.

On the other hand, if #27 is simply a mistake, then surely it would be a bit wasteful to start all over again with a new bug report? I don't mind doing that if you think it's best, but I think it could confuse the issue.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.5 KiB)

This bug was fixed in the package firefox - 10.0+build1-0ubuntu0.10.10.1

---------------
firefox (10.0+build1-0ubuntu0.10.10.1) maverick-security; urgency=low

  * New upstream stable release (FIREFOX_10_0_BUILD1)
    - see LP: #923319 for USN information

  [ Chris Coulson <email address hidden> ]
  * Update patches for PRBool -> bool transition
    - refresh debian/patches/firefox-kde.patch
    - refresh debian/patches/mozilla-kde.patch
    - refresh debian/patches/ubuntu-ua-string-changes.patch
  * Drop some more hanging IPC xpcshell tests
    - update debian/build/testsuite.mk
  * Remove prerm hook for cleaning up pyc files in the apport package-hooks
    folder. Nothing creates these
    - update debian/firefox.prerm.in
  * Set up alternatives in the postinst script on abort-remove too
    - update debian/firefox.postinst.in
  * Imporove maintainer script magic for removing obsolete conffiles when
    upgrading from 3.6, by doing what dpkg-maintscripts-helper does
    - update debian/firefox.postinst.in
    - update debian/firefox.postrm.in
    - update debian/firefox.preinst.in
  * Only run the Apparmor stuff in the postinst script on configure, and
    in the preinst script on install or upgrade, so it handles upgrade failures
    gracefully
    - update debian/firefox.postinst.in
    - update debian/firefox.preinst.in
  * Drop the Ubuntuzilla workarounds now
    - update debian/firefox.postinst.in
  * Refresh patches
    - update debian/patches/allow-lockPref-everywhere.patch
    - update debian/patches/ubuntu_bookmarks.patch
  * Turn off Network Manager integration for now, as it causes Firefox to
    always start in offline mode. In any case, probing Network Manager isn't
    the most reliable way to test if there is a connection
    - update debian/vendor.js
  * Update after landing of bmo: #701875 - Rename omni.jar to omni.ja
    - update debian/firefox.install.in
  * Disable the tests on powerpc, because it sucks too much to run them
    - update debian/rules
  * "Fix" LP: #897794 - some websites expect "X11" to be the first token of
    the platform component in the UA string
    - update debian/patches/ubuntu-ua-string-changes.patch
  * Defuzz ubuntu-codes-google.patch
  * Refresh shipped locales (adds Assamese and Kashubian)
    - refresh debian/config/locales.shipped
    - refresh debian/control
  * Update KDE patches for removal of nsCStringArray
    - update debian/firefox-kde.patch
    - update debian/mozilla-kde.patch
  * Backport changes to allow per-release/per-arch patches
    - add debian/build/enable-dist-patches.pl
    - update debian/rules
  * Fix LP: #908508 - Add patch from upstream to fix powerpc build failure.
    Only apply this patch on powerpc to avoid compromising the quality of
    the architectures that we care about
    - add debian/patches/fix-build-failure-without-yarr-jit2.patch
    - update debian/patches/series
  * Also make the previous powerpc build fix apply on ppc only
    - update debian/patches/series

  [ Micah Gersten <email address hidden> ]
  * Rebase patches for PRBool -> bool transition (bmo: 675553)
    - update debian/patches/allow-lockPref-everywhere.patch
    - update debian/pat...

Read more...

Changed in firefox (Ubuntu Maverick):
status: Triaged → Fix Released
Revision history for this message
Julius Schwartzenberg (jschwart) wrote :

This problem is still in precise as of today. A workaround is to uninstall xul-ext-ubufox. For some reason there is a file included (/usr/share/xul-ext/ubufox/defaults/preferences/ubuntu-mods.js) which sets this preference to false. There is a comment included which indicates this is normally true and could be set to false. Fixing the package to have true in that file would seem to be the appropriate fix.

Seamonkey is not affected by this bug and pasting always works.

Revision history for this message
Alex Selby (launchpad-archduke) wrote :

If anyone is still interested, I can confirm the bug still exists in Lucid after the latest update to firefox 10.0.2+build1-0ubuntu0.10.04.1.

I believe this is not a returning bug. It was incorrectly marked as "fixed" by Launchpad Janitor in reply #27.

Revision history for this message
James Andrewartha (trs80) wrote :

Yes, if you read the full text of the changelog, it contains:
  * Prevent LP: #643899 - Firefox sending header "Accept-Language:
    chrome://global/locale/intl.properties" because the intl.accept_languages
    preference is messed up. Drop a patch which causes the preferences
    system to save a user preference when changing a preference value to equal
    the system default value (and revert to the original behaviour where the
    preference is just discarded). This should hopefully stop Firefox Sync
    from breaking localized preferences where they haven't been modified by
    the user, but does regress LP: #548866

which has been parsed as closing #548866.

Revision history for this message
Arrigo Marchiori (ardovm) wrote :

Confirm the bug is still there:

$ grep middle /usr/share/xul-ext/ubufox/defaults/preferences/ubuntu-mods.js
pref("middlemouse.contentLoadURL", false); // setting to false disables pasting urls on to the page

$ dpkg-query -W firefox
firefox 11.0+build1-0ubuntu0.10.04.2

Revision history for this message
Alex Selby (launchpad-archduke) wrote :

Confirm the bug is still there in Lucid after upgrade to firefox 12.0+build1-0ubuntu0.10.04.1.

So far I've used the launchpad bug report system for two different bugs. On both occasions the bug was not fixed, but was marked as fixed, and we were told to open a new bug report when we pointed out it was not fixed.

I think this is a pity as it discourages people from reporting bugs. They will wonder what the point of opening a new bug report is, if the same thing is going to happen again. (But thanks anyway to people giving their time freely to fixing bugs.)

Adolfo Jayme Barrientos (fitojb)
no longer affects: firefox (Ubuntu Natty)
no longer affects: firefox (Ubuntu Oneiric)
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: In Progress → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → In Progress
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in firefox (Ubuntu Precise):
status: Triaged → Won't Fix
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

The bug assignee didn't login in Bugzilla in the last 7 months.
:KrisWright, could you have a look please?
For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#assignee_no_login.py).

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: In Progress → Confirmed
Revision history for this message
In , Kwright-5 (kwright-5) wrote :

I don't believe this is an issue anymore, and the affected code has been moved and changed so I'm not sure if this is simply not reproducible on my end. I'm going to resolve this with the intent to reopen with new references if someone does reproduce it.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → 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.