Closed
Bug 1416791
Opened 7 years ago
Closed 7 years ago
Reduce the mutability of nsHostObjectURI
Categories
(Core :: Networking, enhancement, P3)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox61 | --- | fixed |
People
(Reporter: valentin, Assigned: valentin)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
Making nsHostObjectURI immutable requires that we get rid of the current mutability, or move it out of the object.
This means ForgetBlobImpl and extending nsSupportsWeakReference should be removed or moved into nsHostObjectProtocolHandler.
Assignee | ||
Comment 1•7 years ago
|
||
- Makes nsHostObjectURI not extend nsSupportsWeakReference
- Tracks blobImpls via nsRefPtrHashtable<nsPtrHashKey<nsIURIWithBlobImpl>, BlobImpl> gBlobTable
- GetBlobImpl and ForgetBlobImpl use the hashtable instead of a member variable
MozReview-Commit-ID: AjLsXMTt1np
Attachment #8927869 -
Flags: feedback?(amarchesini)
Comment 2•7 years ago
|
||
Comment on attachment 8927869 [details] [diff] [review]
Reduce the mutability of nsHostObjectURI
Review of attachment 8927869 [details] [diff] [review]:
-----------------------------------------------------------------
I'm not totally sure I like the 2 tables. Maybe we can merge them and mark DataInfo to be revoked while we are waiting for the timer to delete the data for real.
If we do this, nsHostObjectURI just needs to have a immutable blob URL as string in order to retrieve BlobImpl from gDataTable.
If you do this, you can extend GetDataInfo() to be:
static DataInfo*
GetDataInfo(const nsACString& aUri, bool aConsiderReleasedObject = false)
Also moving nsHostObjectURI code in nsHostObjectProtocolHandler would be nice if it can be avoid.
Attachment #8927869 -
Flags: feedback?(amarchesini) → feedback+
Assignee | ||
Comment 3•7 years ago
|
||
Assignee | ||
Comment 4•7 years ago
|
||
(In reply to Andrea Marchesini [:baku] from comment #2)
> I'm not totally sure I like the 2 tables. Maybe we can merge them and mark
> DataInfo to be revoked while we are waiting for the timer to delete the data
> for real.
> If we do this, nsHostObjectURI just needs to have a immutable blob URL as
> string in order to retrieve BlobImpl from gDataTable.
I have an implementation of this. It makes one relevant change from previous behaviour:
If before we called nsHostObjectProtocolHandler::NewURI(spec), and the blob for spec had just been revoked, then the URI would have a null blobImpl. With this change, it would still be able to find the blobImpl in the table until it's removed by the timer.
Is this OK?
Assignee | ||
Comment 5•7 years ago
|
||
Updated•7 years ago
|
Whiteboard: [necko-triaged]
Updated•7 years ago
|
Priority: -- → P3
Comment hidden (mozreview-request) |
Comment 7•7 years ago
|
||
mozreview-review |
Comment on attachment 8957602 [details]
Bug 1416791 - Eliminate mutability from nsHostObjectURI by removing nsIURIWithBlobImpl
https://reviewboard.mozilla.org/r/226486/#review232588
::: dom/file/nsHostObjectURI.h:31
(Diff revision 1)
> , public nsIURIWithPrincipal
> - , public nsIURIWithBlobImpl
> - , public nsSupportsWeakReference
> {
> private:
> - nsHostObjectURI(nsIPrincipal* aPrincipal,
> + nsHostObjectURI(nsIPrincipal* aPrincipal)
explicit
Attachment #8957602 -
Flags: review?(amarchesini) → review+
Comment hidden (mozreview-request) |
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/aff4d536de14
Eliminate mutability from nsHostObjectURI by removing nsIURIWithBlobImpl r=baku
Comment 10•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Updated•6 years ago
|
status-firefox58:
affected → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•