1366180 - Parent folder link does not work on resource:// urls

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[tfe]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160606114238

Steps to reproduce:

- Open the Url: resource://app/chrome/
- Click on the 'Up to higher level directory' link


Actual results:

Nothing


Expected results:

- Open resource://app/ url

Comment 1

[tfe]

When working on the bug #1365887, i saw that the parent folder link is not working.
I will try to fix this bug too, but i will maybe need a little help as i am discovering the firefox sources right now.

Comment 2

[Loic]

That was the case in the past, with FF33, it works.

Comment 3

[tfe]

Doesn't work on the nightly build, fetched from the latest source.

Comment 4

[Loic]

Story of the bug:

1) It brokes in FF38:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e0cb32a0b1aa&tochange=09f4968d5f42
by
Magnus Melin — Bug 1073095 - nsPermissionManager.cpp references a browser path by default in kDefaultsUrlPrefName. Make the permissions.manager.defaultsUrl pref overridable. r=benjamin

Result: typing resource://app/chrome/ in the location enter sends "File not found".

2) Fixed partially in FF45:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=45273bbed8efaface6f5ec56d984cb9faf4fbb6a&tochange=099f695d31326c39595264c34988a0f4b7cbc698
by
Mike Hommey — Bug 1224000 - Install defaults/permissions file under browser/ instead of under browser/chrome/browser. r=mshal,r=MattN

Result: resource://app/chrome/ is displayed but you can't go back in the folder tree with "Up to higher level directory".

Comment 5

[tfe]

Sorry guys, i think this bug is out of my possibilities right now :).

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Mike, want to take this on? Maybe since you fixed this partially in bug 1224000 you could spot how to fix this too. 

Too late to fix in 53, but if anyone lands a fix for this in 55 please request uplift to 54 if you think it's worth the risk.

Comment 7

[Mike Hommey [:glandium]]

This is actually not related to bug 1224000, but more to bug 1224046.

Here the problem is that links to the parent directory have the jar:file: url as href instead of the resource: url. Arguably the page title is also wrong (Index of jar:file:///... instead of Index of resource://...).

Comment 8

[Mike Hommey [:glandium]]

Attachment: Bug 1366180 - Fix title and parent links in resource:// listings.

For a long time, opening a resource:// url that leads to a file list has
used a title of the form "Index of jar:file://..." where the
jar:file://... url is the actual location the resource:// url has been
resolved to in the omni.ja.

That same url is used to derive a link to the parent directory. Because
of security context restrictions, the resource://... page can't open a
link to jar:file://... .

So we use the original resource:// url to derive the parent directory
link, and while here, also fix the title.

Review commit: https://reviewboard.mozilla.org/r/142132/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/142132/

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 8870659 [details]
Bug 1366180 - Fix title and parent links in resource:// listings.

https://reviewboard.mozilla.org/r/142132/#review145934

The patch looks good. I would love it if we had a test for this. If that's hard to write, or you don't have time for it right now, please file another bug for it.
Thanks!

Comment 10

[Mike Hommey [:glandium]]

I'd write a test if I knew what to test (I guess following links in resource:// listings?) and more importantly had any clue how to test this. My best bet is that it would be a mochitest, but that's about it.

Comment 11

[Valentin Gosu [:valentin] (he/him)]

(In reply to Mike Hommey [:glandium] from comment #10)
> I'd write a test if I knew what to test (I guess following links in
> resource:// listings?) and more importantly had any clue how to test this.
> My best bet is that it would be a mochitest, but that's about it.

I'm with you on this one. Let's file a follow-up bug, and we'll figure this out later.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/056af0b6adda
Fix title and parent links in resource:// listings. r=valentin

Comment 13

[Mozilla Autoland]

We're sorry - something has gone wrong while rewriting or rebasing your commits. The commits being pushed no longer match what was requested. Please file a bug.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/056af0b6adda

Comment 15

[Nathan Froyd [:froydnj]]

Please request uplift on this when you get a chance; it looks like it's low risk enough that it'd be worth taking as a small fix.

Comment 16

[Mike Hommey [:glandium]]

Because the STR in comment 0 used resource://app/, which was broken by bug 1073095, the regression windows in comment 4 ended up wrong.

A better STR, not affected by other bugs:
- Open the Url: resource://gre/chrome/
- Click on the 'Up to higher level directory' link

(gre instead of app)

That places the regression windows on https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91de9c670800&tochange=943b79d9c65f
which pinpoints to bug 1184387, which landed during the 42 cycle, and was uplifted to 41.

Bug 1184387 broke all links in the resource:// pages, and bug 1224046 fixed following children links in 45.

IOW, this has stayed broken and unreported for close to 2 years, I think we can wait a few weeks to have this in a release. resource:// listings are not really a user facing feature anyways (you can only get there manually).

Comment 17

[Nathan Froyd [:froydnj]]

(In reply to Mike Hommey [:glandium] from comment #16)
> IOW, this has stayed broken and unreported for close to 2 years, I think we
> can wait a few weeks to have this in a release. resource:// listings are not
> really a user facing feature anyways (you can only get there manually).

Agreed.  Thanks for the explanation, wontfixing this for 54.