Closed
Bug 794386
Opened 12 years ago
Closed 12 years ago
do not store blob: URIs in global history
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
RESOLVED
FIXED
mozilla19
People
(Reporter: freddy, Assigned: baku)
Details
Attachments
(1 file, 1 obsolete file)
1.86 KB,
patch
|
baku
:
review+
|
Details | Diff | Splinter Review |
blob URIs are very volatile and supposed to be
a) bound to an origin, i.e. only accessible for the origin they were created in.
b) revoked after the document has been unloaded.
I can open blob URIs in other tabs, which creates a history entry. What use is it, to have this history entry?
My suggestion: don't store them in the first place (or remove them on revocation)
I guess this depends on bug 773132, implementing automatic revocation.
Comment 2•12 years ago
|
||
Are you talking about global history here, or session history?
Reporter | ||
Comment 3•12 years ago
|
||
Sorry, I'm not sure about the distinction between global and session history. I'll try to clarify my bug description.
Steps to reproduce:
1) b = new Blob(['foo']); u = window.URL.createObjectURL(b);
2) Then I open the blob URL in a new window (be it with window.open or manually)
3) Restart Firefox
4) Notice that the tabs with the blob URL contain blank pages (blob URIs invalidated?)
5) Close the tabs
6) Open the history (e.g. CTRL+H)
7) Search for "blob:"
8) blob URIs are in the history, but point to something that the browser *knows* is not valid anymore
I hope this doesn't add any confusion.
Comment 4•12 years ago
|
||
That's global history.
Gavin, do you recall whether docshell is supposed to filter URLs for that, or does Places do it?
Comment 5•12 years ago
|
||
Places does most of the filtering, see nsNavHistory::CanAddURI. I think you should just add blob: to its scheme blacklist.
Updated•12 years ago
|
Component: DOM → Places
Product: Core → Toolkit
Reporter | ||
Updated•12 years ago
|
Summary: do not store blob: URIs in history → do not store blob: URIs in global history
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → amarchesini
Comment 7•12 years ago
|
||
Comment on attachment 669105 [details] [diff] [review]
patch 1
Yes, thanks.
Attachment #669105 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 8•12 years ago
|
||
added r=gavin.sharp
Attachment #669105 -
Attachment is obsolete: true
Attachment #669153 -
Flags: review+
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Comment 9•12 years ago
|
||
Status: NEW → ASSIGNED
Keywords: checkin-needed
Updated•12 years ago
|
Flags: in-testsuite+
We're going to need to add 'mediastream' and 'mediasource' to this list. Should we make it a whitelist instead of a blacklist?
Comment 11•12 years ago
|
||
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> Should we make it a whitelist instead of a blacklist?
Yes, I suggested this long time ago, I also think would be better.
Reporter | ||
Comment 12•12 years ago
|
||
FWIW, I agree :)
Assignee | ||
Comment 13•12 years ago
|
||
I agree too, file a bug.
Comment 14•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in
before you can comment on or make changes to this bug.
Description
•