Closed Bug 1224046 Opened 7 years ago Closed 7 years ago
Following links from resource://* listings fails
STR: - 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: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fc5272ac152e8d0fea38ad2e4bd38e6d8aafb744&tochange=6d3e153efe5bff3b3cc4f3690924491aec6856b2 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 ftp://ftp.mozilla.org/pub listing would go to ftp://ftp.mozilla.org/pubmozilla instead of ftp://ftp.mozilla.org/pub/mozilla. I don't know if ftp.mozilla.org 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+
You need to log in before you can comment on or make changes to this bug.