Open
Bug 655681
Opened 13 years ago
Updated 2 years ago
Startup cache stores packaging-time path of js scripts
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
NEW
People
(Reporter: glandium, Unassigned)
Details
When a js script is first stored in the startup cache, the path used to load it initially is stored as well. In the first implementation of part 7 bug 620931, I was loading the js scripts during packaging through jar:/full/path/to/omni.jar!/modules/*.js urls, and these were stored. The next iteration loads through resource:///modules/*.js, which is stored too. When loading from the startup cache, the js script object recovers that file name that was used when the startup cache was created, which doesn't necessarily match the path the script was called with. For instance, in the above case, the jar:/full/path/to/omni.jar!/modules/*.js path obviously doesn't match the omni.jar path at run-time. But even in the next iteration, a script loaded through a resource://gre/ url will have the js script object say it's under resource:///. We can surely imagine some corner cases where this would create problems (such as the one highlighted in bug 620931 comment 51, but in other places. I think we should fixup the js script object to point to the loaded url instead of the stored url.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•