Extend BlobURLChannel to always request and read BlobURL data from parent process
Categories
(Core :: DOM: File, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: ssengupta, Assigned: ssengupta, Mentored)
References
(Blocks 2 open bugs)
Details
Attachments
(12 files, 3 obsolete files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
This is an unobtrusive first step to eliminate broadcast of BlobURLs between content processes. Currently the BlobURL information is shared between hash tables owned by parent process and various content processes. Always requesting the parent process for BlobURLs will render the hash tables owned by content processes needless.
Very brief outline of a possible implementation:
-
BlobURLProtocolHandler should no longer initialize BlobURLChannel with BlobImpl pointer, because unless it is already the parent process, BlobImpl should not be locally available at this stage.
-
The initialization of BlobURLChannel should create a new asynchronous input stream, e.g., BlobURLInputStream.
-
Upon creation, this input stream should request the parent process for a BlobURL over IPC. If parent process responds with success, the input stream will have information on IPCBlob and the corresponding principal.
-
This information can be later used to retrieve actual BlobImpl data by whichever entity wishes to read from the input stream using asyncWait, passing a callback function. In case an input stream is created and not read from, no IPC calls will be generated.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D67119
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
This fix was required for subsequent patches to build successfully, because adding new source files exposed missing dependencies in unified sources.
Assignee | ||
Comment 4•5 years ago
|
||
The content process should use this method to send blob url and triggering principal to the parent process and expect blobImpl in return, if the blob is found and the triggering principal subsumes the blob's principal.
Depends on D75290
Assignee | ||
Comment 5•5 years ago
|
||
Reading from this stream type should be the preferred way to consume data from blob url. When created in the parent process, it requests blob data locally from BlobURLProtocolHandler. When created in a content process, it makes BlobURLDataRequest IPC call to the parent process. Should be wrapped in a nsBufferedInputStream, because ReadSegments() is currently not implemented for this stream type.
Depends on D75291
Assignee | ||
Comment 6•5 years ago
|
||
BlobURLProtocolHandler no longer passes blobImpl pointer to BlobURLChannel. Instead, acquisition and handling of blob data is offloaded to BlobURLInputStream.
Depends on D75292
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
Previously similar logic existed in BlobURLProtocolHandler, which has now been removed, since such checks are now for parent process only and should be abstracted from BlobURLProtocolHandler.
Depends on D75293
Assignee | ||
Comment 8•4 years ago
|
||
Additionally, BlobURLChannel holds no strong reference to BlobURLInputStream. This is to avoid circular dependency.
Depends on D81126
Assignee | ||
Comment 9•4 years ago
|
||
If reading succeeds, it is checked that the length is known from that point on (this check is debug only).
Depends on D81452
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D81718
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
This is done because the test always suffers from shutdown leaks after the changes in Bug 1619953, which make the stream acquired during the test asynchronous.
Depends on D81783
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
Backed out for causing leaks.
backout: https://hg.mozilla.org/integration/autoland/rev/16c92f73e178c26d35c998aac18e24f366400c5b
failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308327207&repo=autoland&lineNumber=30172
[...]
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 imgRequestProxy
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsBaseChannel
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 1 nsDocShell::InterfaceRequestorProxy
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsInputStreamPump
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 2 nsJSPrincipals
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsLoadGroup
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 1 nsNodeWeakReference
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsProgressNotificationProxy
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsProperties
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 5 nsSimpleURI
[task 2020-07-02T14:38:36.686Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 29 nsStringBuffer
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 39 nsTArray_base
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 1 nsThread
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 3 nsURIHashKey
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - TEST-INFO | leakcheck | tab leaked 2 nsWeakReference
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - TEST-UNEXPECTED-FAIL | leakcheck | tab 12928 bytes leaked (BlobURL, BlobURLInputStream, CondVar, CookieJarSettings, CopyOnWriteValue, ...)
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO -
[task 2020-07-02T14:38:36.687Z] 14:38:36 INFO - runtests.py | Running tests: end.
Comment 14•4 years ago
|
||
Also failing on:
Assignee | ||
Comment 15•4 years ago
|
||
The win32 debug test failure seems to be caused by browser/components/attribution/test/browser/browser_AttributionCode_telemetry.js
, when I disable this test, bc3
no longer fails for win32 debug.
Example test run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=578ffbb7dbae0af65b1b2164fb902187b47a46ee&selectedTaskRun=SjxpidHbTHq3u9woGQG76Q.0
When I run that test on a cross-compiled win32 debug build in a win64 environment, the test passes. It is not clear to be at all if this failure is related to my work. Is there something else I can try to reproduce this failure locally, so that I can try to fix it?
Comment 16•4 years ago
|
||
On the try push it looks like it doesn't fail on bc3 anymore, but it still fails on bc2 as it's moving chunks (seen in the push which was backed out too).
Have you imported the patches on a try push and added all jobs?
Updated•4 years ago
|
Assignee | ||
Comment 17•4 years ago
|
||
Instead of creating a new (non-private) window, the first existing window is used. Mime type added during blob creation. Other minor adjustments made.
Updated•4 years ago
|
Assignee | ||
Comment 18•4 years ago
|
||
The test was found to fail for various builds in try runs for Bug 1656033. Running manually on the latest mozilla central at this time, the test did not pass for Linux and Windows 64 bit debug. This should be more closely investigated at a later time.
Filed Bug 1656033 to re-enable.
Depends on D85139
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 19•4 years ago
|
||
The test was found to fail for various builds in try runs for Bug 1656033. Running manually on the latest mozilla central at this time, the test kept timing out for Linux and Windows 64 bit debug. This should be more closely investigated at a later time.
Filed Bug 1656510 to re-enable.
Depends on D85313
Updated•4 years ago
|
Assignee | ||
Comment 20•4 years ago
|
||
Depends on D85313
Updated•4 years ago
|
Comment 21•4 years ago
|
||
Comment 22•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/18f5967c6264
https://hg.mozilla.org/mozilla-central/rev/4023d64db104
https://hg.mozilla.org/mozilla-central/rev/962b1016439e
https://hg.mozilla.org/mozilla-central/rev/67ea7d621ba6
https://hg.mozilla.org/mozilla-central/rev/e917c642bcd1
https://hg.mozilla.org/mozilla-central/rev/e26c24b59a29
https://hg.mozilla.org/mozilla-central/rev/258a4545fadc
https://hg.mozilla.org/mozilla-central/rev/bc827fb0f4de
https://hg.mozilla.org/mozilla-central/rev/1e1523043d23
https://hg.mozilla.org/mozilla-central/rev/21c1e0210d45
https://hg.mozilla.org/mozilla-central/rev/82321c8cba45
https://hg.mozilla.org/mozilla-central/rev/5409c44e043f
Description
•