Open Bug 655681 Opened 13 years ago Updated 2 years ago

Startup cache stores packaging-time path of js scripts

Categories

(Core :: XPCOM, defect)

defect

Tracking

()

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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.