Closed
Bug 42249
Opened 25 years ago
Closed 25 years ago
res handler not resolving location correctly.
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jud, Assigned: jud)
Details
Attachments
(1 file)
from adam:
It appears that when Gecko tries to first load a URL, it loads this agent style
sheet:
res://res/ua.css
The res channel resolves this into a local file name, e.g.
d:\mozilla\bin\res\ua.css
And then loads it up.
Unfortunately, if the host app is not running from d:\mozilla\bin, the resolved
path is wrong! Embedding apps such as CBrowse
run from elsewhere so that the URL is resolved to something like:
d:\cbrowse\debug\res\ua.css
The agent stylesheet file isn't there so no content is displayed and there are
asserts everywhere.
I believe the reason for this is that the nsResProtocolHandler class mistakenly
does this at the start of its Init() method:
// make "res:///" == "resource:/"
rv = SetSpecialDir("", "system.OS_CurrentProcessDirectory");
if (NS_FAILED(rv)) return rv;
It's using the current working directory for resolving res files and not the
Mozilla bin directory. Fortunately the fix is easy.
Change the "system.OS_CurrentProcessDirectory" to "xpcom.currentProcess".
There's also a questionable call at the end of Init() that may also need
changing:
// Set up the "Resource" root to point to the old resource location
// such that:
// resource://<path> == res://Resource/<path>
rv = SetSpecialDir("Resource", "system.OS_CurrentProcessDirectory");
if (NS_FAILED(rv)) return rv;
Comment 2•25 years ago
|
||
All these special directory names are unspecified (you have to dig through the
source), so it's no wonder there's a problem here. Please check in the change to
xpcom.currentProcess if that works.
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•