280442 - A bad downloads.rdf file causes firefox to crash on download - FF11a1 [@ nsDownloadsDataSource::GetURI]

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Meni]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050115 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050115 Firefox/1.0+

I got firefox to crash on downloads. I renamed the file downloads.rdf to a
differrent name to hide it from firefox and everything worked ok.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Meni]

Attachment: A bad download.fdr file

Comment 2

[OstGote!]

Could you provide a Talkback incident ID (crash report)?

Comment 3

[OstGote!]

(In reply to comment #2)
> Could you provide a Talkback incident ID (crash report)?

please see if you have components\talkback.exe, if you do, please run it and see
if it lists any incidents, if not, please run the ff installer, select custom
install, select talkback, repeat the steps to crash, follow the directions,
repeat these steps. if you have an incident id, please mention it here in this
report. thanks

Comment 4

[Meni]

Talkback incident ID: TB3674347M

ty guys for a great product!

Comment 5

[timeless]

Incident ID: 3674347
Stack Signature	nsDownloadsDataSource::GetURI() 8a198e5c
Product ID	FirefoxTrunk
Build ID	2005020816
Trigger Time	2005-02-13 11:29:08.0
Platform	LinuxIntel
Operating System	Linux 2.6.10-1.760_FC3
Module	firefox-bin + (005dc3df)
URL visited	
User Comments	
Since Last Crash	8 sec
Total Uptime	8 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.
/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 848
Stack Trace 	
nsDownloadsDataSource::GetURI() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 848]
RDFServiceImpl::UnregisterDataSource() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/rdf/base/src/nsRDFService.cpp,
line 655]
nsDownloadManager::~nsDownloadManager() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 145]
nsDownloadManager::Release() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 129]
nsDownloadManagerConstructor() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/build/nsModule.cpp,
line 74]
nsGenericFactory::CreateInstance() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/build/nsGenericFactory.cpp,
line 86]
nsComponentManagerImpl::CreateInstanceByContractID() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/components/nsComponentManager.cpp,
line 1965]
nsComponentManagerImpl::GetServiceByContractID() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/components/nsComponentManager.cpp,
line 2385]
CallGetService() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/build/nsComponentManagerUtils.cpp,
line 90]
nsGetServiceByContractIDWithError::operator() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/build/nsComponentManagerUtils.cpp,
line 287]
nsCOMPtr_base::assign_from_gs_contractid_with_error() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/build/nsCOMPtr.cpp,
line 141]
nsDownloadProxy::Init()
nsExternalAppHandler::InitializeDownload() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,
line 2103]
nsExternalAppHandler::CreateProgressListener() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,
line 842]
nsExternalAppHandler::LaunchWithApplication() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,
line 2420]
nsExternalAppHandler::OnStartRequest() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,
line 1758]
nsDocumentOpenInfo::OnStartRequest() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 848]
nsUnknownDecoder::FireListenerNotifications() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/streamconv/converters/nsUnknownDecoder.cpp,
line 600]
nsUnknownDecoder::OnDataAvailable() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/streamconv/converters/nsUnknownDecoder.cpp,
line 191]
nsDocumentOpenInfo::OnDataAvailable() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 848]
nsStreamListenerTee::OnDataAvailable() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/base/src/nsStreamListenerTee.cpp,
line 842]
nsHttpChannel::OnDataAvailable() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 3878]
nsInputStreamPump::OnStateTransfer() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 440]
nsInputStreamPump::OnInputStreamReady() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 341]
nsInputStreamReadyEvent::EventHandler()
PL_HandleEvent() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c,
line 699]
PL_ProcessPendingEvents() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c,
line 633]
nsEventQueueImpl::ProcessPendingEvents() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/nsEventQueue.cpp,
line 417]
event_processor_callback() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 67]
libglib-2.0.so.0 + 0x479c7 (0x002e19c7)
libglib-2.0.so.0 + 0x237bb (0x002bd7bb)
libglib-2.0.so.0 + 0x25242 (0x002bf242)
libglib-2.0.so.0 + 0x254ef (0x002bf4ef)
libgtk-x11-2.0.so.0 + 0x10b07e (0x0083707e)
nsAppShell::Run() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 141]
nsAppStartup::Run() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
xre_main() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/xre/nsAppRunner.cpp,
line 830]
main() 
[/builds/tinderbox/firefox/Linux_2.4.20-28.8_Clobber/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
libc.so.6 + 0x14e33 (0x004fce33)

Comment 6

[Frank Wein [:mcsmurf]]

btw: Your invalid downloads.rdf was caused by Bug 281969, which is fixed now. I
couldn't reproduce your crasher so (here i just couldn't download anything
further and JS Console spit out a error).

Comment 7

[Jay Patel [:jay]]

I'm seeing similar/related crashes in early Deer Park Alpha 1 Talkback data:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsDownloadsDataSource::GetURI&vendor=MozillaOrg&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Here is a recent incident:
Incident ID: 6327722
Stack Signature	nsDownloadsDataSource::GetURI 2f1aa7a1
Product ID	FirefoxTrunk
Build ID	2005053112
Trigger Time	2005-06-02 06:27:28.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (003e9bd2)
URL visited	n/A
User Comments	Clicked the Security-Tab in the options Dialog, I installed Deer
Park just a minute ago.
Since Last Crash	44 sec
Total Uptime	44 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 1566
Stack Trace 	
nsDownloadsDataSource::GetURI 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 1566]
nsDownloadManager::~nsDownloadManager 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,
line 146]
nsComponentManagerImpl::GetService 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/components/nsComponentManager.cpp,
line 2111]
nsJSCID::GetService 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcjsid.cpp,
line 899]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2100]
XPC_WN_CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1348]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1182]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3473]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1202]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1279]
js_InternalGetOrSet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1322]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3299]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1202]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsXULDocument::ResumeWalk 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 3205]
nsXULDocument::OnStreamComplete 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 3451]
nsStreamLoader::OnStopRequest 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsStreamLoader.cpp,
line 137]
nsJARChannel::OnStopRequest 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/modules/libjar/nsJARChannel.cpp,
line

Adding topcrash info and confirming to new.

Comment 8

[Udo Richter]

Attachment: testcase downloads.rdf

I have a reduced testcase downloads.rdf file that reproducibly crashes on 'Deer
Park' FF1.1 Alpha 1 and Alpha 2. The file is stripped down to three download
entries (each of them seems to be necessary) and four blocks of filling bytes
with precisely adjusted size.

On an important side note, the downloads.rdf does NOT validate as XML by
Firefox although it IS valid. Because of that, I think there is a serious XML
parser bug causing this. On load into the browser, Forefox complains about line
618:

    <NC:ProgressPercent NC:parseType="Integer">100</NC:ProgressPercent>

.. and demands a closing tab </NC:PogressPercent>. Seems as if the parser
dropped the 'r' from the opening tab somehow. Maybe this XML parsing error
causes a special case of termination in the download manager, triggering this
crash. (~nsDownloadManager() in trace looks like emergency shut down to me.)

Talkbacks:
TB7441645M
TB7400646G

Comment 9

[Udo Richter]

I've nailed down the XML error. These things combined confuse the parser:

1. The XML charset encoding is not set, causing it to be read as UTF-8
2. There's a letter 'ä' in "Westeuropäische Normalzeit" encoded as ISO-8859-1
   (ascii 0xE4, invalid UTF-8 3 byte character)
3. The 'ä' letter is at file offset 0xCFFF
4. The broken tag is at file offset 0xE000

So in fact the file IS malformed, because of the invalid UTF character and/or
the missing ISO-8859-1 encoding.

Comment 10

[Udo Richter]

Filed bug 301797 about the UTF-8 decoder dropping a byte, causing this crash.
Two issues remain anyway:

- The rdf file needs either a proper character set declaration or valid UTF-8
encoding,
- There's probably some un-checked error return from the parser that causes the
crash.

Comment 11

[O. Atsushi (Torisugari)]

(In reply to comment #10)
> - The rdf file needs either a proper character set declaration or valid UTF-8
> encoding,

It can't be valid UTF-8 encoding, because NC:parseType="Date" is encoded in 
the system dependent charset (::strftime() tells us "timezone").

Comment 12

[Mike Connor [:mconnor]]

Not a topcrasher in DPA2, 2 crahes on 07/23 for trunk, but the UTF-8 fix should
prevent those from happening.  There's still a theoretical crash here, but users
shouldn't see this.

Comment 13

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

I think that I am seeing a crash with this signature (see TB11177244Y ).

Is there a way I can test whether this is the the same problem, and
if so what still needs doing.

I was selecting the privacy pane in the preferences dialogue.

I am not sure which profile I was using at the time, but nearly all my
'downloads.rdf' are not well formed with data like:

    <NC:DateStarted NC:parseType="Date">&#65533;&#65533;&#65533;&#65533;&#65533;&#65533;&#65533;i&#65533;&#65533;U&#65533;&#65533;&#65533;&#65533;&#65533;}&#65533;&#65533;&#65533;&#720;&#65533;)&#65533;&#65533;&#65533;&#65533;&#65533; +636011</NC:DateStarted>

on line 9.

I do also get a crash nearly every time I save a file, at the point when
the temporary filename is replaced by the true one. I have never been able to
catch this in the debugger, and I had assumed that it it was something
that I was doing wrong, but I suspect that that stack was the same. Certainly
the crash happens at one of the virtual functions named GetURI( ).

I may have a another talkback ID for that one.

Comment 14

[Ben Fowler]

It is TB11213038E , I was saving a PDF file. For the past several months(!),
I have avoided using Firefox to download files, copying the URL and using
curl instead.

In this case the 'downloads.rdf' was not well formed at line 9:

    <NC:DateStarted NC:parseType="Date">ø&#711;’¿±»&#63743;i&#305;ê&#8734;U§ø&#711;’–}Ñê±ÀêØ)îø&#711;’– +636011</NC:DateStarted>

Comment 15

[Anders Rødland]

I have additional information about this bug. If my computer restarts (not a controlled windows shutdown/restart) for whatever reason, the "download.rdf" get corrupted and this bug occurs (firefox crashes whenever I try to start it, I must delete "download.rdf" to fix it).

- Anders

Comment 16

[Daniel Veditz [:dveditz]]

Would need a trunk-baked patch to consider for 1.8.0 branch   

Comment 17

[Dave Townsend [:mossop]]

*** Bug 326186 has been marked as a duplicate of this bug. ***

Comment 18

[Dave Townsend [:mossop]]

*** Bug 326525 has been marked as a duplicate of this bug. ***

Comment 19

[Ben Fowler]

If I created a patch for this, would it be considered?

Should we delete the bad rdf file when we see it, or paper over the crash, or
what?

Comment 20

[timeless]

i'd rather we rename it, but that's the personal opinion of an end user who rarely uses the product in question :). please create the patch.

Comment 21

[Jenny]

As often as this file goes bad on me I'd rather a patch to fix it. Thanks.

Comment 22

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060320 Firefox/1.6a1

It is possible that the patch I have in mind is already in, in which case I 
don't understand comment 16 .

It would be good if anyone affected by Bug 326525 "Download Manager won't open 
and when I try it causes firefox to error and close" or Bug 326186 "crash when 
i download anything" could check with a more recent build. It is possible that 
this bug is currently WORKSFORME .

I wonder whether the patch checked in for Bug 328113 "crash [@ 
nsMimeType::GetDescription]" has fixed this. Compare Bug 328113 comment 0 with 
my comment 13 and with the two bugs I quoted above.

Comment 23

[Dave Townsend [:mossop]]

*** Bug 326525 has been marked as a duplicate of this bug. ***

Comment 24

[Steve England [:stevee]]

*** Bug 332100 has been marked as a duplicate of this bug. ***

Comment 25

[Steve England [:stevee]]

*** Bug 332112 has been marked as a duplicate of this bug. ***

Comment 26

[Jesse Ruderman]

nsDownloadsDataSource::GetURI jumped from being the #73 topcrash in Firefox 1.5.0.1 to being the #2 topcrash in Firefox 1.5.0.2.  Does anyone know why?  Should I file a new bug?

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, it's bug 328113.  Although this original report may actually be a duplicate of it...

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

But the fix for bug 328113 wasn't ideal -- we should really recover better from the corruption; these example downloads.rdf files may help debug the problem.

Comment 29

[Daniel Veditz [:dveditz]]

Is this still a potential blocker if the fix for bug 328113 goes in?

Comment 30

[Jay Patel [:jay]]

Marking topcrash+, but -'ing for 1.8.0.3 in hopes bug 328113 will fix the topcrash.  We can revisit this next time if the crash continues and someone comes up with a patch.

Comment 31

[Steve England [:stevee]]

*** Bug 336016 has been marked as a duplicate of this bug. ***

Comment 32

[William]

*** Bug 336998 has been marked as a duplicate of this bug. ***

Comment 33

[Adam Guthrie]

*** Bug 325868 has been marked as a duplicate of this bug. ***

Comment 34

[Adam Guthrie]

Attachment: downloads.rdf causing TB18433672Q

This is a downloads.rdf someone was using when they reported this crash on IRC today. As expected, deleteting dowloads.rdf fixed the crash.

Comment 35

[Ben Fowler]

(In reply to comment #34)
> Created an attachment (id=221296) [edit]
> downloads.rdf causing TB18433672Q

Are you sure that this is the same problem?

It seemed to me that the key feature of this one was the presence of 'nsDownloadsDataSource::GetURI()' in the stack, see comment 2

You problem whilst it may centre on CallGetService() seems to crashing at 
nsIconChannel::GetName( ). I would have guessed that you are seeing a 
different "downloads.rdf => 'crash on download'" bug ...

See 
Bug 328113 "crash [@ nsIconChannel::GetName][@ nsMimeType::GetDescription]
[@ nsDownloadsDataSource::GetURI]"
Bug 253624 "Browser crashes and hangups whenever I try to download 
flashplayer or try to save any file or picture"
Bug 332884 "1.5.0.1 release crashes when I'm trying to download gtk 2.8.16 taballs [@ nsDownloadsDataSource::GetURI]"

I'll freely admit that I don't understand the relationship between this bug and bug 328113, also I had thought that this bug was no longer reproducible (see comment 1 , comment 8 and my comment 13 ).

Comment 36

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060509 Minefield/3.0a1(In reply to comment #35)

> (In reply to comment #34)
> > Created an attachment (id=221296) [edit]
> > downloads.rdf causing TB18433672Q

I set up a new profile (which had no downloads.rdf in it at all) and copied 
the downloads.rdf from TB18433672Q to it.

Trying to reproduce TB18433672Q, I downloaded the link http://personal.riverusers.com/~thegrendel/abs-guide-3.8.tar.bz2, and got 
no crash.

Am I missing some step?

Note that the provided file seemed to be 'not well formed' and truncated at 
around 837, the last few characters being:     <NC:DateEnded NC:parseTy

Comment 37

[Ben Fowler]

(In reply to comment #36)
> [ snip ]
> Note that the provided file seemed to be 'not well formed' and truncated at 
> around 837, the last few characters being:     <NC:DateEnded NC:parseTy

Bugzilla ate my last paragraph:  

This would to appear to bring us back to comment 11 , and my view that this 
bug is about not crashing when an RDF file is not well formed. If there is code
in Firefox that can create not well formed files (such as this one) then 
that needs to be fixed independently, as happened in Bug 301797 . Of course, 
I may on quite the wrong lines ...

Comment 38

[timeless]

attachment 222093 [details]

Comment 39

[Thomas Bertels]

attachment 172898 [details] doesn't reproduce.
attachment 189169 [details], attachment 221296 [details] and attachment 222093 [details] (comment #38) are the same bug 328113.

Comment 40

[Thomas Bertels]

*** Bug 301642 has been marked as a duplicate of this bug. ***

Comment 41

[Thomas Bertels]

*** Bug 303746 has been marked as a duplicate of this bug. ***

Comment 42

[Thomas Bertels]

*** Bug 337913 has been marked as a duplicate of this bug. ***

Comment 44

[Shawn Wilsher :sdwilsh]

Fixed by Bug 380250