Closed Bug 747041 Opened 8 years ago Closed 8 years ago

resource:///modules/ and resource://gre/modules/ should be clearly-differentiated

Categories

(Firefox Graveyard :: Web Apps, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 14

People

(Reporter: t.matsuu, Assigned: t.matsuu)

Details

(Whiteboard: [qa-])

Attachments

(2 files)

The difference of resource:///modules/ and resource://gre/modules/ is exposed by building Firefox on top of xulrunner. So these two resource URLs are clearly-differentiated.


browser/modules/webappsUI.jsm:
WebappsInstaller.jsm is imported from resource://gre/modules/.
However it locates at resource:///modules/.

browser/modules/WebappsInstaller.jsm:
Three files (Services.jsm, FileUtils.jsm, and NetUtil.jsm) are imported from resource:///modules/.
However they exist at resource://gre/modules/.

browser/components/places/content/places.js:
MigrationUtils.jsm is imported from resource://gre/modules/.
However it locates at resource:///modules/.
Felipe or Myk - Any ideas?
If I understand this correctly, Takanori is saying that when you build Firefox on top of XULRunner, with the two inhabiting different directories, then resource:///modules/ and resource://gre/modules/ represent two different locations, and some references to modules in those locations are currently referencing the wrong location.

This hasn't shown up in our test builds and in nightly builds because those put Firefox and the underlying platform (the GRE) into the same directory.  So it doesn't affect our ability to ship Firefox with the runtime.  But we should still make our code work for Takanori's use case and correct our references to these modules.
(In reply to Takanori MATSUURA from comment #0)
> browser/components/places/content/places.js:
> MigrationUtils.jsm is imported from resource://gre/modules/.
> However it locates at resource:///modules/.

this is tracked in bug 739968, fwiw, I think we can fix it in hours.  Btw, surely the non-difference between the 2 paths in common browser builds is quite error-prone (as you can see we keep using the wrong path).
(In reply to Myk Melez [:myk] [@mykmelez] from comment #2)
> If I understand this correctly, Takanori is saying that when you build
> Firefox on top of XULRunner, with the two inhabiting different directories,
> then resource:///modules/ and resource://gre/modules/ represent two
> different locations, and some references to modules in those locations are
> currently referencing the wrong location.

You are right.
At least, Fedora and RHEL build Firefox on top of xulrunner.
In this case,
resource://gre/modules/ represents jar:file:///usr/lib64/xulrunner-14/omni.ja!/modules/ and
resource:///modules/ represents jar:file:///usr/lib64/firefox/omni.ja!/modules/
If anyone wants to provide a patch to the webapps{ui,installer} I can review it
Another wrong path found in browser/base/content/browser.js.
Attachment #616923 - Flags: review?(felipc)
Blocks: 731054
Attachment #616920 - Flags: review?(felipc) → review+
Attachment #616923 - Flags: review?(felipc) → review+
https://hg.mozilla.org/mozilla-central/rev/c823e4f03017
Assignee: nobody → t.matsuu
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
No longer blocks: 731054
Felipe - Is there anything needed to be verified from an end-user perspective? Doesn't look like it, but I'd like to confirm.
Whiteboard: [qa-]
Jason: no, nothing necessary
Flags: in-moztrap-
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.