On linux, if a sharedlib dependency is missing, PR_LoadLibrary simply fails. On Windows, the OS displays a dialog box by default. Since PR_LoadLibrary is frequently used to do runtime detection of libraries, this dialog is bad UI. We can wrap the PR_LoadLibrary impl on windows with SetErrorMode() to avoid this dialog.
Created attachment 173707 [details] [diff] [review] Wrap LoadLibrary() in SetErrorMode()
Attachment #173707 - Flags: review?(wtchang)
From MSDN: "Each process has an associated error mode that indicates to the system how the application is going to respond to serious errors. A child process inherits the error mode of its parent process. Because the error mode is set for the entire process, you must ensure that multi-threaded applications do not set different error-mode flags. Doing so can lead to inconsistent error handling." Do we care?
I doubt that we want to make this change in NSPR; If we were going to do this, XPCOM would be the better place was we are the ones more likely to load a library that has missing depend libraries. Wan-Teh, would a better place for this patch be in XPCOM? These dialogs aide discovery of what installation problem there might be. Is there an alternative way this information can be generated by the user and be given to someone in tech support/customer service? Also, this dialog may be the least of the user's worries, right? If the component failed to load, chrome or other core functionality may be hosed, right? Probably in a seperate bug, we should discuss making xpcom smarter the way it loads (or fails to load) components. If we drop this dialog, it make make sense for xpcom to raise a dialog with simple information about the failure.
Nono! The point is that missing dependencies are a normal+expected occurence, and should not be reported to the user (think gdi+). We already removed the "could not load component" warning from the console output, because on linux we use this to do runtime detection of gssapi and such.
So instead of flattening the entire thing, why not have a LoadButWeDontCareIfThisFails call instead? Then we still know about required stuff missing without any unneeded stuff when 'testing' if something is there.
This bug is a duplicate. Error mode is a process-wide property. A library like NSPR should refrain from setting a process property. An application is in the best place to do that. I agree that we should disable the error dialog, but it should be the applications (Mozilla, Firefox, Thunderbird, etc.) that should do that. Even XPCOM may not be the right place to do that. The fact that the attached patch is not thread-safe is irrelevant. *** This bug has been marked as a duplicate of 278328 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Attachment #173707 - Flags: review?(wtchang) → review-
You need to log in before you can comment on or make changes to this bug.