check isFile before fileSize (loading engines may fail at startup)

RESOLVED FIXED in Firefox 2 alpha3

Status

()

P1
normal
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Gavin, Assigned: Gavin)

Tracking

({fixed1.8.1})

2.0 Branch
Firefox 2 alpha3
fixed1.8.1
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Apparently at least the Mac GetFileSize throws if the file is a directory, so this causes problems when loading engines.
Created attachment 222751 [details] [diff] [review]
patch
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #222751 - Flags: review?(mconnor)
Attachment #222751 - Flags: approval-branch-1.8.1?(mconnor)
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileOSX.cpp&rev=1.38&mark=731,733,736,739#725

I'm not sure where the NS_ERROR_FILE_NOT_FOUND exception is coming from. Either CFURLGetFSRef is failing in nsLocalFile::GetFSRefInternal, or ::FSGetCatalogInfo is returning fnfErr which gets mapped to NS_ERROR_FILE_NOT_FOUND by MacErrorMapper. I couldn't find any relevant descriptions of the failure conditions for those functions in the Carbon docs, and I'm not familiar with those APIs at all, so I'm guessing that one of those will fail for a directory. The Windows implementation of GetFileSize returns 0 for a directory, and from inspection the Unix version seems to do the same. I guess I should file a bug on at least documenting that in the IDL.
Flags: blocking-firefox2?
Priority: -- → P1
In case somebody is looking for this here are the exceptions that Dietrich was seeing at startup:

Error: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.fileSize]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: nsSearchService.js :: SRCH_SVC_loadEngines :: line 1697"  data: no]

Error: uncaught exception: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/search/search.xml :: get_searchService :: line 112"  data: no]

Updated

13 years ago
Flags: blocking-firefox2? → blocking-firefox2+

Updated

13 years ago
Attachment #222751 - Flags: review?(mconnor)
Attachment #222751 - Flags: review+
Attachment #222751 - Flags: approval-branch-1.8.1?(mconnor)
Attachment #222751 - Flags: approval-branch-1.8.1+
mozilla/browser/components/search/nsSearchService.js 	1.1.2.21
Keywords: fixed1.8.1
Whiteboard: [checkin needed]
Target Milestone: Firefox 2 beta1 → Firefox 2 alpha3
mozilla/browser/components/search/nsSearchService.js 	1.26
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]

Comment 6

13 years ago
(In reply to comment #2)
> I
> guess I should file a bug on at least documenting that in the IDL.
> 

did you file a bug?
You need to log in before you can comment on or make changes to this bug.