Closed Bug 1416791 Opened 7 years ago Closed 7 years ago

Reduce the mutability of nsHostObjectURI

Categories

(Core :: Networking, enhancement, P3)

enhancement

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.
- 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 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+
(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?
Whiteboard: [necko-triaged]
Priority: -- → P3
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+
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/aff4d536de14 Eliminate mutability from nsHostObjectURI by removing nsIURIWithBlobImpl r=baku
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: