[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [Git][tpo/applications/tor-browser][tor-browser-153.6.0esr-16.0-1] 6 commits: Bug 1822968 - Match downloaded filenames structure to Desktop a=RyanVM



Title: GitLab

ma1 pushed to branch tor-browser-153.6.0esr-16.0-1 at The Tor Project / Applications / Tor Browser

Commits:

  • a724d9f3
    by Gela at 2026-10-27T10:41:46+01:00
    Bug 1822968 - Match downloaded filenames structure to Desktop  a=RyanVM
    
    Original Revision: https://phabricator.services.mozilla.com/D312566
    
    Differential Revision: https://phabricator.services.mozilla.com/D333355
    
  • 09c4187c
    by Ryan VanderMeulen at 2026-10-27T10:41:52+01:00
    Bug 2076098 - Update FreeType to d1f916a65eb1. r=jfkthame
    
    Differential Revision: https://phabricator.services.mozilla.com/D330588
    
  • afd09abf
    by Jens Stutte at 2026-10-27T10:41:57+01:00
    Bug 2076695 - Make nsTimer support thread-safe weak pointers and hold it weakly from nsTimerImpl.  a=RyanVM
    
    Original Revision: https://phabricator.services.mozilla.com/D331822
    
    Differential Revision: https://phabricator.services.mozilla.com/D335165
    
  • 2ea1d53b
    by Jon Coppeard at 2026-10-27T10:42:02+01:00
    Bug 2077075 - Remove marking check that doesn't hold r=spidermonkey-reviewers,iain
    
    There's a block at the start of ShouldMarkCrossCompartment that crashes if it
    detects gray to nursery edges, on the grounds that it shouldn't be possible for
    such edges to exist.
    
    The reasoning is wrong and this bug demonstrates how they can be created: by
    wrapper remapping, which touches gray (and possibly dead) things.
    
    It's not a problem to hit these edges here. We will return false from the first
    if block because the nursery target will be reported as marked black. The
    nursery object will be tenured and traced on the next minor GC, due to the
    store buffer entry added by the postbarrier when we created the edge.
    
    Differential Revision: https://phabricator.services.mozilla.com/D331524
    
  • 0f54e8e3
    by Nika Layzell at 2026-10-27T10:42:07+01:00
    Bug 2077257 - Improve ThreadSafeWeakPtrHashKey behaviour during an object's destructor, r=sergesanspaille a=dmeehan DONTBUILD
    
    Currently ThreadSafeWeakPtrHashKey is defined fully in terms of the
    concrete referenced type, meaning that it cannot work late during an
    object's lifecycle, after the object's refcount has reached 0 and during
    the destructor. I expect that removing entries from a table during the
    destructor is a clear use-case for this type, meaning that it would be
    better if we supported this.
    
    This patch does this by simplifying the handling of `ThreadSafeWeakPtr`
    such that it's used directly, and slightly improving the ergonomics of
    the underlying type so that it can be used directly in this way.
    
    Original Revision: https://phabricator.services.mozilla.com/D331272
    
    Differential Revision: https://phabricator.services.mozilla.com/D335325
    
  • 5790737d
    by DonalMe at 2026-10-27T10:42:13+01:00
    Bug 2077257 - Fix ESR153 build a=bustage
    

101 changed files:

The diff was not included because it is too large.
_______________________________________________
tor-commits mailing list -- tor-commits@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-commits-leave@xxxxxxxxxxxxxxxxxxxx