Skip to content

[BUG] Disable Auto Joining Raids does not prevent Twitch redirect (Firefox, 7TV 1.10.0) #1264

Description

@lansman

Description

The Disable Auto Joining Raids setting is enabled, but Twitch still automatically redirects to the raided channel when a broadcaster ends the stream with a raid.

7TV is otherwise loaded and working on the page: the 7TV settings button and 7TV chat features are visible, and the setting remains enabled when the settings panel is reopened.

Environment

  • 7TV: 1.10.0 (Firefox AMO "7TV New", extension ID seventv-next@7tv.app)
  • Firefox: 156.0.1
  • OS: macOS
  • Site: twitch.tv
  • FrankerFaceZ: 4.80.4.0, enabled
  • 7TV Enable FrankerFaceZ Compatibility Mode: enabled
  • BetterTTV: disabled

Steps to reproduce

  1. Open a Twitch channel with 7TV active.
  2. Open 7TV Settings → Chat → General.
  3. Enable Disable Auto Joining Raids.
  4. Wait for the broadcaster to start a raid.
  5. Do not click the manual join button.
  6. Wait for the raid countdown to finish.

Current behavior

Twitch automatically navigates to the raided channel despite Disable Auto Joining Raids being enabled.

Expected behavior

7TV should leave/cancel an automatically joined raid and keep the current page from navigating. Manual raid joins should remain possible.

Additional information

  • The 7TV setting was checked again after the incident and was still enabled.
  • The extension has permission to access the twitch.tv domain.
  • This report concerns the new 1.10.0 extension, not the legacy 3.1.x build.
  • I have not claimed nightly verification because the public repository's nightly/template appears to target the legacy extension line.

Activity

  1. lansman commented on Oct 2, 2026

    @lansman
    Author

    I investigated this against the official Firefox packages for 7TV New 1.7.2, 1.10.0, and 1.10.2, and compared the implementation with current FrankerFaceZ and BetterTTV.

    The failure is in 7TV's React component lookup, before the actual raid handling runs.

    RaidAutojoinModule registers its component hook with the equivalent of:

    {
      childSelector: "#root",
      predicate: isRaidController,
      maxDepth: 300,
    }

    However, the shared React hook resolver treats childSelector as a DOM element rendered below the target component and therefore walks up the Fiber chain via fiber.return. It treats parentSelector as a container and scans down through child/sibling fibers.

    Twitch's #root is the React root container and RaidController is below it. As a result, the current lookup walks in the wrong direction, finds no RaidController, and never installs the handleJoinRaid wrapper or calls handleLeaveRaid(). This explains why the setting remains enabled in the UI but has no effect.

    There is a second issue in the same resolver: the downward (parentSelector) branch calls the descendant traversal without forwarding maxDepth, so it silently uses the helper default of 100 instead of the requested 300.

    The relevant logic is unchanged in the 1.7.2, 1.10.0, and 1.10.2 Firefox bundles. I also reproduced both lookup failures with a synthetic Fiber tree.

    This does not look like a current Twitch RaidController API regression:

    Suggested fix:

    1. Change the root lookup to parentSelector: "#root".
    2. Forward { maxDepth: selector.maxDepth ?? 100 } to the descendant Fiber traversal.

    Alternatively, a more resilient implementation would observe [data-test-selector="raid-banner"] and find the owning component upward from that DOM node, similar in spirit to BetterTTV's approach. That avoids scanning the entire Twitch root and reduces dependence on tree depth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions