Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #18811

Closed (moved)
Open
Opened Apr 13, 2016 by Arthur Edelstein@arthuredelstein

Our first-party isolation patch incorrectly rejects blobs retrieved in workers

When isolation is enabled, blobs retrieved by an XHR inside a worker are rejected even when the blob's first party matches the worker's first party. I found that the regression was caused by this Mozilla patch: https://hg.mozilla.org/mozilla-central/diff/12a852867c16/dom/base/nsXMLHttpRequest.cpp#l1694

Because of the Mozilla patch, when we are in a worker, NS_NewChannel is no longer passed a document, so our patch code in nsHostObjectProtocolHandler::NewChannel2 is not able to obtain the correct first party. Therefore the blob URI is rejected even if the first party of the worker matches. I haven't yet figured out how to fix this problem.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#18811