Closed Bug 574458 Opened 14 years ago Closed 14 years ago

firefox 3.6.4 crashes with some extensions iff extensions.ini is present

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Version:
3.6 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED DUPLICATE of bug 551152
Tracking Flags:
Tracking Status
status1.9.2 --- wanted

People

(Reporter: J.S.Peatfield, Unassigned)

References

Details

(Whiteboard: [oopp-watchlist]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.14eol) Gecko/20100331 (For DAMTP) Red Hat/1.0.9-0.52.el3 SeaMonkey/1.0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.4) Gecko/20100623 Red Hat/3.6-8.el5 Firefox/3.6.4

I added my observations to 574334 but was told to report a separate bug, so here it is.

In 574334 I said:

I think we may be seeing a similar behaviour with the "MR Tech toolkit"
extension https://addons.mozilla.org/en-US/firefox/addon/421/ (currently
release 6.0.4).

One of our users reported problems after we updated to Firefox 3.6.4 (BTW this
is the SL5/RHEL5 Linux package), testing it myself I find that after adding the
extension it restarts firefox and seems ok, but after quitting any later
attempt to start it results in a segv.

Going into the extensions/{9669CC8F-B388-42FE-86F4-CB5E7F5A8BDC}/ and taking a
look about I find that if I manually rename components/nightly.xpt to (say)
components/nightly.xpt.OFF then firefox no longer crashes and the extension
appears to work ok.

Another hack is to remove the extensions.ini which lets firefox work *just* for
the next time it is started (and then it gets recreated with the same contents)
so it seems to be related to whatever processing is done there.

I'm tempted to tweak our firefox wrapper we have to always delete all the
extensions.ini files but that does seem rather evil...

--

since then we have observed the same problem with the "Delicious bookmarks" extension and again removing the extensions.ini before starting firefox appears to 'fix' it - just for that run.  I assume that the removal of random stuff from inside the extensions trees isn't good for them so maybe the problem lies somewhere else.

I'm informed by the user who first reported this problem that he has no such crashes using firefox 3.6.4 on Ubuntu 9.10 so maybe this is RedHat/SL specific (but I don't have easy access to other systems to test right now).

Reproducible: Always

Steps to Reproduce:
1. start firefox 3.6.4
2. install "MR Tech toolkit" from https://addons.mozilla.org/en-US/firefox/addon/421/ 
3. let firefox restart - the extension seems to be working and then quit
4. start firefox, and it crashes
5. remove the extensions.ini from the profile directory and it will start up without problems.
Actual Results:  
A segv during startup, e.g.

$ firefox
/usr/lib/firefox-3.6/run-mozilla.sh: line 131:  6890 Segmentation fault      "$prog" ${1+"$@"}


Expected Results:  
the extension should not cause firefox to crash, or the presence of the .ini file shouldn't affect the behaviour.

I'm leaving the severity at minor even though it causes a crash since it only affects those with certain extensions and may only happen on the RedHat/SL build of firefox 3.6.4

I did get a gdb dump by running firefox -g but that contains no useful information since the symbols appear to have been stripped from the xulrunner libs - I include it in case it means anything to you.

$ firefox -g
MOZILLA_FIVE_HOME=/usr/lib/firefox-3.6
  LD_LIBRARY_PATH=/usr/lib/firefox-3.6:/usr/lib/firefox-3.6/plugins:/usr/lib/firefox-3.6:/usr/lib64/openmpi/1.2.7-gcc/lib
DISPLAY=localhost:14.0
FONTCONFIG_PATH=/etc/fonts:/usr/lib/firefox-3.6/res/Xft
DYLD_LIBRARY_PATH=/usr/lib/firefox-3.6:/usr/lib/firefox-3.6
     LIBRARY_PATH=/usr/lib/firefox-3.6:/usr/lib/firefox-3.6/components:/usr/lib/firefox-3.6
       SHLIB_PATH=/usr/lib/firefox-3.6:/usr/lib/firefox-3.6
          LIBPATH=/usr/lib/firefox-3.6:/usr/lib/firefox-3.6
       ADDON_PATH=/usr/lib/firefox-3.6
      MOZ_PROGRAM=/usr/lib/firefox-3.6/firefox
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/lib/firefox-3.6/run-mozilla.sh: line 118: type: ddd: not found
/usr/bin/gdb /usr/lib/firefox-3.6/firefox -x /tmp/mozargs.LY8654
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/lib/firefox-3.6/firefox '-UILocale' 'en-GB'
(no debugging symbols found)
(no debugging symbols found)
.... (lots more of this)...
Detaching after fork from child process 8709.
(no debugging symbols found)
[New Thread 0xf4bbcb90 (LWP 8711)]
(no debugging symbols found)
[New Thread 0xf3fffb90 (LWP 8712)]
(no debugging symbols found)
[New Thread 0xf35feb90 (LWP 8713)]
[New Thread 0xf2bfdb90 (LWP 8714)]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 0xf1fffb90 (LWP 8716)]

Program received signal SIGSEGV, Segmentation fault.
0xf6a0454a in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
(gdb) where
#0  0xf6a0454a in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#1  0xf6a05c05 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#2  0xf6a076de in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#3  0xf6a07a4a in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#4  0xf6aefaaa in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#5  0xf6d223d5 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#6  0xf6d22b5e in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#7  0xf63e2388 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#8  0xf63e2bc8 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#9  0xf63e3328 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#10 0xf6d223d5 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#11 0xf6d22b5e in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#12 0xf6293b03 in ?? () from /usr/lib/xulrunner-1.9.2/libxul.so
#13 0xf62908d2 in XRE_main () from /usr/lib/xulrunner-1.9.2/libxul.so
#14 0x08049a5f in __gxx_personality_v0 ()
#15 0xf7bf9e8c in __libc_start_main () from /lib/libc.so.6
#16 0x08049611 in __gxx_personality_v0 ()
(gdb) 


BTW this particular box is an x86_64 machine but running the 32-bit firefox, we see the same problems on 32-bit machines as well.
I just tested this on the same host as before but with a download of firefox 3.6.4 binary from firefox.com (http://www.mozilla.com/en-US/products/download.html?product=firefox-3.6.4&os=linux&lang=en-US)

Starting with a clean new profile I went to https://addons.mozilla.org/en-US/firefox/addon/421/ installed it and the restart went ok, however on a restart it didn't segv - just quit with exit code 1.

ie with firefox -g on this version I see:

jp107@floggle-toggle:/tmp/firefox $ ./firefox -g
./run-mozilla.sh -g ./firefox-bin
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:.:/usr/lib64/openmpi/1.2.7-gcc/lib
DISPLAY=localhost:19.0
DYLD_LIBRARY_PATH=.:.
     LIBRARY_PATH=.:./components:.
       SHLIB_PATH=.:.
          LIBPATH=.:.
       ADDON_PATH=.
      MOZ_PROGRAM=./firefox-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
./run-mozilla.sh: line 118: type: ddd: not found
/usr/bin/gdb ./firefox-bin -x /tmp/mozargs.c14725
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /tmp/firefox/firefox-bin 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
... lots more of this...

[New Thread 0xf560bb90 (LWP 14835)]
(no debugging symbols found)
[New Thread 0xf4affb90 (LWP 14836)]
(no debugging symbols found)
[New Thread 0xf40feb90 (LWP 14837)]
[New Thread 0xf36fdb90 (LWP 14838)]
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread 0xf4affb90 (LWP 14836) exited]
[Thread 0xf560bb90 (LWP 14835) exited]
[Thread 0xf40feb90 (LWP 14837) exited]
[Thread 0xf36fdb90 (LWP 14838) exited]

Program exited with code 01.
(gdb) 

again removing the extensions.ini from the profile-directory is enough to make it start up.

So at least it seems that the RHEL/SL build isn't to blame here (well I'm not sure if firefox exiting with code 1 is any better than crashing).

This firefox has the ident string:

  Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

in case it helps at all.

I also checked that unsetting LD_LIBRARY_PATH didn't fix it (in case the openmpi libs were the cause) - it didn't make any difference.

I still don't know if this just affects Linux machines running RHEL5/SL5 though.
It's an extension with binary components (.xpt) and such an extension can always crash the browser.
Whiteboard: [oopp-watchlist]
Is bug 575048 a duplicate then?
Yeah I think so. As I read it, the reporter was using m.o builds in that bug as well, but it's hard to tell.
I can reproduce it with debug build of 1.9.2:

*** Registering components in: nsUnixProxyModule
*** Registering components in: jsctypes
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/fuel/application;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/browser/sessionstartup;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/browser/browserglue;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/privatebrowsing;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/scriptsecuritymanager;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/embeddor.implemented/web-content-handler-registrar;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: Cannot create startup observer : service,@mozilla.org/appshell/trytoclose;1: file nsAppStartupNotifier.cpp, line 113
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
++DOCSHELL 0x7f92a3f6e400 == 1
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3455
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E: file nsDocShell.cpp, line 1297
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E: file nsWebShellWindow.cpp, line 241
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E: file nsAppShellService.cpp, line 372
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E: file nsAppShellService.cpp, line 182
WARNING: NS_ENSURE_SUCCESS(rv, 1) failed with result 0x8007000E: file nsAppRunner.cpp, line 3375
###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1017

...and exit
The missing interface is nsIXPCComponents, "155809f1-71f1-47c5-be97-d812ba560405".
ftp://ftp.mozilla.org/pub/firefox/nightly/

Would someone that can reproduce this check the 1.9.2 builds between 2010-04-01 3.6.3 and 2010-06-11 3.6.4 for a regression range. Getting the hg revision for the working and failing builds would be a great help. The hg revisions can be found by typing about:buildconfig in the address bar.
blocking1.9.2: --- → ?
status1.9.2: --- → wanted
Well a quick test shows that it fails for me on SL/RHEL5 using the version from
ftp://ftp.mozilla.org/pub/firefox/nightly/2010/01/2010-01-01-03-mozilla-1.9.2
which was a 3.6beta

[ The reason I reported it for 3.6.4 is that RH jumped from 3.0.19 to 3.6.4 so it may well have been broken at any point between those releases. ]

I'll try some earlier versions and see where the problem seems to have appeared...

 -- Jon
blocking1.9.2: ? → ---
Oops I forgot to include the info from about:buildconfig for the above version:

  Built from http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6d13e4351efc

Also going back further the earlier version of the 1.9.2 versioning that I can find also fails:

ftp://ftp.mozilla.org/pub/firefox/nightly/2009/08/2009-08-13-10-mozilla-1.9.2/firefox-3.6a2pre.en-US.linux-i686.tar.bz2

  Built from http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c7d1cd3d77a7

but a similar age 1.9.1 tree doesn't show this problem e.g. the version from ftp://ftp.mozilla.org/pub/firefox/nightly/2009/08/2009-08-14-03-mozilla-1.9.1/firefox-3.5.3pre.en-US.linux-i686.tar.bz2

  Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/45436bc0b7fd

seems to work for me...

So it seems to have affected every version of 3.6 from the earliest alpha, but not the equivalent 3.5 (alpha/beta) versions which were being built at the same time...

Or maybe my testing is flawed in some way (downloaded each binary and simply run it using the same test profile which has the "MH tech toolkit" extension added to it).  The failing ones all worked (once) when the previous version that was run is different or if I remove the extensions.ini file from the profile directory.

BTW my firefox profiles trees don't contain any symlinks though my home directory happens to be over NFS and this is not the same filesystem where I had downloaded the firefox nightly builds into) in case that is likely to be a factor.
So this is before 1.9.2 branched so you would need to follow the mozilla-central builds to find the date of the regression.

The 1.9.1 builds are going to be Firefox 3.5 builds which you have mention that they work above.
Ok going back with the mozilla-central nightly versions I see that this seems to be that last one that works:

 2009-07-08:
  Built from http://hg.mozilla.org/mozilla-central/rev/845fd6b1ef23

and this is the next version I can find and it fails:

 2009-07-09:
  Built from http://hg.mozilla.org/mozilla-central/rev/0d2fc193cd1f

I've no idea how to find what changed between those two but I hope someone who knows more about the system can.
hmm not much in there that would expect to affect extensions ...

Ok another data point...  the versions which failed for me above all work if I test from an account with home directory on local disk rather than being automounted via NFS...

In fact if I just set HOME to point to where the home directory is actually mounted then it seems to work - so maybe the problem is that there is a symlink along the way to $HOME...

e.g. normally my HOME is set to /home/raid/supp/jp107 with /home/raid being an am-utils generated symlink to where the NFS fs is really mounted:

  ls -ld /home/raid
  lrwxrwxrwx 1 root root 15 May 28 23:02 /home/raid -> /DAMTP/cinghome/

and just setting HOME=/DAMTP/cinghome/supp/jp107 avoids it seeing this symlink and all then works as expected.

So maybe this problem really is the result of the changes to how path comparisons are done as a result of:

  http://hg.mozilla.org/mozilla-central/rev/51bafb458d68

Though why it causes firefox to quit (or crash) - but only if extensions.ini is present is presumably a different bug that this change has revealed...
It's because firefox fails to load the nightly.xpt component and thus some of the default components are missing because loading of the rest it chanceled.

(gdb) f
#0  xptiInterfaceInfoManager::DoFullValidationMergeFromFileList (this=0x7fffe0c10680, aSearchPath=0x7fffe0c09390, aFileList=
    0x7fffe0c094e0, aWorkingSet=0x7fffffffd3b0) at xptiInterfaceInfoManager.cpp:1097
1097	in xptiInterfaceInfoManager.cpp

(gdb) ps name
$11 = 0x7fffffffd240 "nightly.xpt"

(gdb) bt
#0  xptiInterfaceInfoManager::DoFullValidationMergeFromFileList (this=0x7fffe0c10680, aSearchPath=0x7fffe0c09390, aFileList=
    0x7fffe0c094e0, aWorkingSet=0x7fffffffd3b0) at xptiInterfaceInfoManager.cpp:1097
#1  0x00007ffff6efdfdb in xptiInterfaceInfoManager::AutoRegisterInterfaces (this=0x7fffe0c10680)
    at xptiInterfaceInfoManager.cpp:1943
#2  0x00007ffff6ef8152 in xptiInterfaceInfoManager::GetInterfaceInfoManagerNoAddRef () at xptiInterfaceInfoManager.cpp:101
#3  0x00007ffff6e7ccbb in NS_InitXPCOM3_P (result=0x7fffffffdb20, binDirectory=0x7fffec01c180, appFileLocationProvider=
    0x7fffffffd970, staticComponents=0x7ffff79e5340, componentCount=52) at nsXPComInit.cpp:766
#4  0x00007ffff5b715dc in ScopedXPCOMStartup::Initialize (this=0x7fffffffdb20) at nsAppRunner.cpp:1109
#5  0x00007ffff5b78486 in XRE_main (argc=1, argv=0x7fffffffe068, aAppData=0x7fffec021080) at nsAppRunner.cpp:3273
#6  0x0000000000401f2f in main (argc=1, argv=0x7fffffffe068) at nsBrowserApp.cpp:158
As far as it fails in xptiWorkingSet::FindDirectoryOfFile()/xptiWorkingSet::FindDirectory() 

it seems to be this fix for nsLocalFile::Equals():

http://hg.mozilla.org/mozilla-central/rev/51bafb458d68
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think the problem (at least for my box) is caused by symlinks. The profile I use is located at /media/store1/Dokumenty/.mozilla but I have a symlink /home/komat/.mozilla => /media/store1/Dokumenty/.mozilla. 

I get then in nsLocalFile::Equals for nightly.xpt:

inPath = /home/komat/.mozilla/firefox/9bd60pjz.default/extensions/{9669CC8F-B388-42FE-86F4-CB5E7F5A8BDC}/components
mPath = /media/store1/Dokumenty/.mozilla/firefox/9bd60pjz.default/extensions/{9669CC8F-B388-42FE-86F4-CB5E7F5A8BDC}/components
I met a similar bug in '89 in a common-lisp system where 'truename' did symlink expansion but not everything used that code so sometimes stored pathnames didn't match themselves...  oops.

If pathnames stored in the extensions.ini (or anywhere else) are absolute and need to match what is found in the filesystem then I assume that things will also break if the user's home directory (or profile-directory) gets moved...
Depends on: 576111
i think this is a dupe of bug 551152
Depends on: 551152
(In reply to comment #21)
> i think this is a dupe of bug 551152

That seems likely.  When I first read that bz I thought it didn't apply... I'd not considered that a symlink anywhere in the pathname might cause the problems.

I note that in 551152 comment 26 there is a suggestion that it is fixed in recent mozilla-central builds, though by some changes which might not be so desirable to back-port to the (stable) 3.6.x series.

I can't easily verify if the recent mozilla-central builds fix it since the extensions I have that show the problem only claim to be compatible up to 3.7a5pre so won't load on anything newer.
No longer depends on: 551152
Note: We think this issue is the same as "our" bug https://bugzilla.mozilla.org/show_bug.cgi?id=574334
you're welcome to have your own opinions, but they don't count for much, sorry.
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 576111
Resolution: --- → DUPLICATE
bug 551152 has been closed since it is fixed in mainline - but the bug still exists in 3.6.x.  Can the patch in there which was for use against the 1.9.2 tree be considered again please?

https://bugzilla.mozilla.org/attachment.cgi?id=431372
Version: unspecified → 3.6 Branch
bug 551152 is against Trunk where apparently it is alrerady fixed.   So I'm re-opening this since it isn't fixed in 3.6.x
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
that's not how we do business. do not reopen
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
In some sense yes it is a DUP since at the time of the original report the bug was present in both trees; but it got fixed only in Trunk and not the 1.9.2 branch.

So should I report a new bug explicitly against 1.9.2 branch or will that also be marked as a DUP?  Or should the status of 551152 be altered to indicate that it was only resolved for Trunk?

Should bug reports about the same underlying flaw in (say) thunderbird etc also get marked as DUP?

Having read https://developer.mozilla.org/en/Screening_duplicate_bugs and https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla I can't see the proper procedure for when an unfixed bug is marked a DUP of one for a different revision (or product) where it has already been fixed.

Or I may have failed to find the right description.
they've indicated they aren't interested in backporting the changes. there's nothing more to discuss anywhere.

filing more bugs in order to antagonize engineers is a good way to invite someone to terminate your account.

resolutions default to meaning trunk. for things which are fixed on other branches with the same bug, we use flags.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
#  No whining about decisions. If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug should be reopened.
Status: RESOLVED → VERIFIED
FWIW, https://bugzilla.mozilla.org/show_bug.cgi?id=551152#c33 and https://bugzilla.mozilla.org/show_bug.cgi?id=551152#c35 from the patch author and code reviewer respectively are in favor of the patch added to the branch.  The patch status is also "approval1.9.2.8?" which means it's on the table for 3.6.8.  Complaining in bugs won't make it go any faster.
My last comment for this bug - an apology.

(In reply to comment #29)
> they've indicated they aren't interested in backporting the changes. there's
> nothing more to discuss anywhere.

Ok we had found a workround that stops our users complaining I was just trying to help others.

> filing more bugs in order to antagonize engineers is a good way to invite
> someone to terminate your account.

I didn't mean to imply that anyone should file pointless bugs.  Just that that the problem exists in at least thunderbird 3.1 as well as firefox 3.6 I wondered how the bug-reporting procedures were supposed to work.  I did e-mail you to ask but I now see that was yet another breach of mozilla etiquete.  Sorry about that.

> resolutions default to meaning trunk. for things which are fixed on other
> branches with the same bug, we use flags.

Ok, I'll try to understand the flags next time I look at a bug.

> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> #  No whining about decisions. If a respected project contributor has marked a
> bug as INVALID, then it is invalid. Someone filing another duplicate of it does
> not change this. Unless you have further important evidence, do not post a
> comment arguing that an INVALID or WONTFIX bug should be reopened.

Thanks for the pointer. I'll try to avoid whining in future.

(In reply to comment #30)
> FWIW, https://bugzilla.mozilla.org/show_bug.cgi?id=551152#c33 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=551152#c35 from the patch author
> and code reviewer respectively are in favor of the patch added to the branch. 
> The patch status is also "approval1.9.2.8?" which means it's on the table for
> 3.6.8.  Complaining in bugs won't make it go any faster.

Again sorry; I just saw the headline "RESOLVED WORKSFORME" for the fix in Trunk and assumed that this meant no fix for the 1.9.2 tree.

Once again sorry for any trouble I have caused you.
You need to log in before you can comment on or make changes to this bug.