Closed Bug 1224046 Opened 8 years ago Closed 8 years ago

Following links from resource://* listings fails


(Core :: Networking, defect)

Not set



Tracking Status
firefox45 --- fixed


(Reporter: glandium, Assigned: glandium)




(1 file)

- Open resource://app/
- Click on one of the links

Expected result:
- Link opened

Actual result:
- Nothing happens. Browser console mentions a Security Error: Content at resource://app/ may not load or link to jar:file:///...

mozregression points me to:

which points to bug 1184387 as the starting point of the breakage. Now, obviously, that was done for a good reason, so the question is how we should work around it.

A simple thing that works is to remove the <base href> from the directory listing page, but I'm not sure what implications that would have for non-resource:// listings.
So, there was an attempt to remove the base href from the directory listings in bug 358128, but that was backed out because of ftp listings, where, aiui, a 'mozilla' link on e.g. the listing would go to instead of

I don't know if had something special back then, but trying a few ftp servers, I'm always "redirected" to a url ending with a / when going to a ftp url of a directory that doesn't end with a /. And it looks like this wasn't actually happening back in the 1.5 days (I tested FF 1.5 on windows).

So I guess we may be safe to remove that base href now.
This doesn't seem to cause regressions in the test suite.
Assignee: nobody → mh+mozilla
Attachment #8686485 - Flags: review?(mcmanus)
Comment on attachment 8686485 [details] [diff] [review]
Remove <base href> from directory listings

Review of attachment 8686485 [details] [diff] [review]:

I'm ok with trying it out
Attachment #8686485 - Flags: review?(mcmanus) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Depends on: 1232287
Depends on: 1367583
You need to log in before you can comment on or make changes to this bug.