Closed Bug 63178 Opened 25 years ago Closed 24 years ago

OS/2 - JPEG/PNG not loaded sometimes

Categories

(SeaMonkey :: General, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: dmitry, Assigned: mkaply)

Details

Run warpzilla w/o home page, try to load JPEG from local drive. Here is log: Document about:blank loaded successfully ************************************************** nsNativeComponentLoader: GetFactory(J:\MOZ\MOZILLA\DIST\BIN\components\nsjpg.dll) Load FAILED with error: error 2 ************************************************** Document file:///E:/Olympus/2mil/2500_g.jpg loaded successfully
duplicate of 63125?
*** This bug has been marked as a duplicate of 63125 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reopening this bug becouse can't reopen bug 63125 Using 2001-03-27 build. More info: 1. Mozilla bin dir not present in LIBPATH. DLLs are loaded becouse "." present in LIBPATH 2. Current browser session should be "just loaded", i.e. no any JPEG/PNG images loaded. 3. "current directory" should be changed using "Open File Ctrl-O" command, i.e. open image from local drive. Result: nsjpeg/nspng could not load becouse mozjpeg/mozpng not in current dir. Solution: * Add mozilla bin dir to LIBPATH (bad if you have more than one mozilla) * Do not change current dir for application on file picker. * Pre-load dlls on startup (perfomance issue)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: OS/2 - JPEGs not loaded sometimes → OS/2 - JPEG/PNG not loaded sometimes
Seems valid to me. I would propose to enhance the OS/2 NSPR DLL loading mechanism to query the path of the EXE and try to load the DLL from there as the very first attempt. What do you think about that Mike?
Status: UNCONFIRMED → NEW
Ever confirmed: true
We could do that. I can't recreate the problem though. Which file picker are you using?
Using generic OS/2 file picker .
JPEG/PNG are loaded by the OS/2 LX loader when nsjpeg/etc get loaded because we have a module dependency on them. Therefore they have to be in the LIBPATH. No way to change that as long as we dynaload jpeg/png.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WONTFIX
This isn't needed anymore - JPEG and PNG aren't separate DLLs
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.