Opened 21 months ago

Last modified 21 months ago

#22414 needs_information defect

Chrome object URLs are not revoked after New Identity

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-newnym, tbb-regression, tbb-6.0-issues
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #15502 this problem is completely described, but applied measures don't solve it.
The docs say "Browsers will release these automatically when the document is unloaded". So, either document is never unloaded, or Mozilla forgot to implement this.
Testcase is also in #15502 (creates blobs even when JS is disabled).
Leftovers are visible in about:memory:

35 (100.0%) -- dom-media-stream-urls
├──22 (62.86%) -- owner unknown
│  ├───1 (02.86%) ── blob:null/25779196-2491-42e5-8f69-4e52ac6ceb65
│  ...
├───8 (22.86%) -- owner(resource://pdf.js/build/pdf.worker.js)
│   ├──1 (02.86%) ── blob:resource://pdf.js/1ef14a0f-a417-47cb-9955-8b9f18a43e2c
│   ...
└───1 (02.86%) ── owner(https://people.torproject.org/~mikeperry/transient/tests/blob-uri-creation.html)/blob:https://people.torproject.org/e66522b9-85ea-4743-a773-aab2deb7bdc5

Child Tickets

Change History (5)

comment:1 Changed 21 months ago by gk

Keywords: tbb-regression tbb-6.0-issues added
Status: newneeds_information

It seems this regression got introduced with Tor Browser 6.0. However, testing an ESR52-based Tor Browser does not show the same problem for me. Could you test with a recent alpha (https://dist.torproject.org/torbrowser/7.0a4/) and report whether the problem is solved for you as well?

comment:2 Changed 21 months ago by cypherpunks

Status: needs_informationnew

This situation is greatly improved on alpha, some blobs are removed right after tab closing, but after New Identity some of them are still observable

2 (100.0%) -- file-blob-urls
└──2 (100.0%) -- owner unknown
   ├──1 (50.00%) ── blob:null/29449f13-5207-45d3-84df-2923a6b089de
   └──1 (50.00%) ── blob:null/e0ea787a-7e20-4037-8d47-71b7019a44b3

comment:3 in reply to:  2 ; Changed 21 months ago by gk

Status: newneeds_information

Replying to cypherpunks:

This situation is greatly improved on alpha, some blobs are removed right after tab closing, but after New Identity some of them are still observable

2 (100.0%) -- file-blob-urls
└──2 (100.0%) -- owner unknown
   ├──1 (50.00%) ── blob:null/29449f13-5207-45d3-84df-2923a6b089de
   └──1 (50.00%) ── blob:null/e0ea787a-7e20-4037-8d47-71b7019a44b3

Is that in the main process or is that web content? What do you do to create those? Which operating system are you on?

comment:4 in reply to:  3 Changed 21 months ago by cypherpunks

Replying to gk:

Is that in the main process or is that web content?

Main, after enabling e10s by removing add-on :(

What do you do to create those?

Nothing, just browsing.

Which operating system are you on?

Win 7.

comment:5 Changed 21 months ago by gk

Priority: HighMedium
Severity: MajorNormal
Summary: Object URLs are not revoked, even after New IdentityChrome object URLs are not revoked after New Identity

Okay, so this is not content process related which is good. However, I can't reproduce your problem, neither on Linux nor on my Windows 7 machine: after New Identity there are no blob resources left for me. Do you have by chance some steps to reproduce? I just surfed a bit and once the blob URI(s) showed up I hit New Identity and as fast as I could I measured again in the new session and found nothing.

What do those URIs show if you load them in a new tab? For instance, blob:null/aea79f34-6db6-4940-a978-c07c910a552a shows the DuckDuckGo icon. If you look further and set memory.blob_report.stack_frames to a non-null value (I used 10) you'll get even stack frames showing where the URI is coming from. In my case it was search related.

Note: See TracTickets for help on using tickets.