188448 - can't get from about:cache-entry to cached copy

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect, P3)

Description

[Jesse Ruderman]

From timeless in bug 66299 comment 11:

"right now i can get to
about:cache-entry?client=image&sb=0&key=http://bugzilla.mozilla.org/attachment.cgi?id=111028&action=view
but the link it has is to the url instead of to the cached data."

I agree with timeless that there should at least be a "view cached copy" link or
button in the cache-entry page.

Comment 1

[Jesse Ruderman]

And it would be nice if there were a way to save the cached copy.

Comment 2

[Prognathous]

As a workaround, switch Mozilla (or Firefox) to work offline, then load the page
or save the file.

Prog.

Comment 3

[Alfred Kayser]

Probably not valid (any more?)
Although the key in about:cache?device=disk doesn't directly jump to the content but to the cache-entry page for that entry, via:
about:cache-entry?client=HTTP&sb=1&key=http://w3.ibm.com/ui/v8/scripts/scripts.js

When one clicks on the key URL in that cache-entry you get to the cached content itself.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

that revalidates the content, or even just refetches it.

Comment 5

[chAlx]

(Can't set links so posting similar bug in text: Bug 188448)

Actually the Disk cache entry information page has the "file on disk" field with the data needed. It just should be converted into URL with the "file://" prefix.

The memory cache entry has "file on disk: none" line; this "none" could be URLed in some other manner. (Then "on disk" suffix should be trimmed.)

Comment 6

[chAlx]

Similar bug 492230

Comment 7

[Steffen Wilberg]

(In reply to chAlx from comment #5)
> Actually the Disk cache entry information page has the "file on disk" field
> with the data needed. It just should be converted into URL with the
> "file://" prefix.

I can certainly linkify the path, but clicking the link throws:
"Security Error: Content at about:cache-entry?client=HTTP&sb=1&key=http://xxx.jpg may not load or link to file:///home/xxx/.cache/mozilla/firefox/xxxxxxxx.default/Cache/x/xx/xxxxxxxx."

That's CheckLoadURIError:
http://mxr.mozilla.org/mozilla-central/source/caps/src/nsScriptSecurityManager.cpp#1339

Other about pages are not that picky; the same file:// link hacked into about: works just fine. What's going on?

Comment 8

[Boris Zbarsky [:bzbarsky]]

"about:" is a system-principal page (it's actually a redirect to "chrome://global/content/about.xhtml").

about:cache-entry does not have any special privileges, so isn't allowed to do privileged stuff.

Comment 9

[Steffen Wilberg]

Attachment: poc

Thanks. So, this is a proof of concept patch.

- Assigns the system principal to about:cache-entry. Is that a good idea?

- I copied NS_NewInputStreamChannel because I needed access to the channel so I could call SetOwner on it. Is all that code necessary?

- Prepends "<a href="file://" to the "file on disk" paths. Those paths appear according to the platform, e.g. on Linux /home/user/.cache/ and on Windows C:\whatever. However, linking to "file://C:\whatever" works fine on Windows.
Should I programmatically retrieve the "file://" URI instead?

- If so, what would be the right way to do that?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 732111 [details] [diff] [review]
poc

> - Assigns the system principal to about:cache-entry. Is that a good idea?

Unclear.

If the only reason we want this is so that we can link to file://, can we get there with some sort of expanded principal?  Jonas?

> Is all that code necessary?

Not at all.  You can just call NS_NewInputStreamChannel, then set the owner on the result.

> Should I programmatically retrieve the "file://" URI instead?

I think just prepending file:// to an absolute path is fine.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 732111 [details] [diff] [review]
poc

Sorry, I don't know how the expanded principal stuff works.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 732111 [details] [diff] [review]
poc

Mounir, do you?

Comment 13

[Mounir Lamouri (:mounir)]

Comment on attachment 732111 [details] [diff] [review]
poc

Expanded principal will allow a principal to be same origin with multiple origins IIRC.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Hmm.

So if all we want out of this principal is to allow linking to file:// and nothing else, could we just make it a principal for file:/// ?

Comment 15

[Mounir Lamouri (:mounir)]

I'm afraid there might be a misunderstanding: nsExtendedPrincipal has nothing to do with files or B2G. It was done for JetPack for content scripts IIRC. I'm not sure how they can help with file:///, which, IIRC, have one principal per file path, right?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Hence the question in comment 14.  Do we need to subsume file:// principals here, or just be able to link to file:// URIs?

Comment 17

[Steffen Wilberg]

Attachment: poc v2

Less code thanks to comment 10.
Still using the system principal.

Comment 18

[Steffen Wilberg]

Attachment: poc v3

How about adding a special case to nsScriptSecurityManager.cpp instead?

Comment 19

[Steffen Wilberg]

Try builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d7ae99b92b6b

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 742721 [details] [diff] [review]
poc v3

I would much rather keep the hackery to about:cache-entry instead... especially because some other Gecko app could implement it in a way that does not need such privileges, but would still be stuck with the same security manager hack.

Comment 21

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 22

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 23

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:dragana, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:kershaw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 27

[Randell Jesup [:jesup] (needinfo me)]

Things may well have changed in the last 11 years; you can see the data for the cached item, but it's displayed in a hexdump visual format; so not easy to save off. I'm not sure if this fully covers the original request; however there seem to have been no further requests in the meantime. Closing as WONTFIX given bz's comments on the patch and lack of interest.