Github rule does not prevent duplicate tabs for the same ticket number, even when unique asserted

[stevecalvert]

The sample rules provide configuration for GitHub Issues. It looks like this should be able to distinguish unique tickets based on the "URL Matcher" group capture, /issues/(\d+)

But when the unique flag is set, duplicate tabs for the same ticket are still shown

My understanding was that this might have been resolved by #473. The tests in this PR have examples that specify the captured group in the URL Fragment

it('should process single capture group correctly', () => {
		const urlFragment = 'https://mysite.atlassian.net/browse/$1';

but if I try to modify the Github rule along the same lines, by changing the URL Fragment from github\.com/.+/issues/(\d+) to github\.com/.+/issues/$1, then no tickets are recognized at all

Expected behavior
If there are two tabs that match the URL Fragment rule, the most recently created tab is closed

Extension version:
1.1.1

[sebastienfontaine]

Hi @stevecalvert,

Thank you for reporting this issue! You've identified a fundamental architectural limitation in how Tab Modifier currently handles the unique flag with URL patterns.

The Problem

You're absolutely right that the current implementation doesn't work as expected. Here's why:

The url_fragment field currently serves two conflicting purposes:

1. Detection - Determine if a rule should apply to a tab
2. Uniqueness - Determine if two tabs are duplicates

This creates an impossible situation:

Why $1 in url_fragment doesn't work:

{
  "detection": "CONTAINS",
  "url_fragment": "github.com/issues/$1",
  "tab": {
    "unique": true,
    "url_matcher": "github\\.com/.+/issues/(\\d+)"
  }
}

❌ CONTAINS detection: The URL doesn't literally contain the string "$1", so the rule never matches

❌ REGEX detection: $1 in regex means "end of line followed by 1", which is invalid for detection

Why removing $1 doesn't work either:

{
  "detection": "REGEX",
  "url_fragment": "github\\.com/.+/issues/\\d+",
  "tab": {
    "unique": true,
    "url_matcher": "github\\.com/.+/issues/(\\d+)"
  }
}

✅ Detection works, but ❌ all issues return the same processed value, so issue #123 and issue #456 are considered duplicates and one gets closed.

Why PR #473 doesn't solve this:

PR #473 improved the unique tab logic by checking if tabs match the url_matcher pattern before comparing them (this prevents closing unrelated tabs like Gmail). However, it doesn't solve the fundamental conflict between detection and uniqueness.

The Solution (Proposed)

I've documented a comprehensive solution that introduces a new optional field unique_pattern:

{
  "detection": "REGEX",
  "url_fragment": "github\\.com/.+/issues/\\d+",
  "tab": {
    "unique": true,
    "url_matcher": "github\\.com/.+/issues/(\\d+)",
    "unique_pattern": "github.com/issues/$1"
  }
}

This separates concerns:

• url_fragment → Detection only (any valid regex/pattern)
• unique_pattern → Uniqueness only (template with $1, $2, etc.)

Benefits:

• ✅ Each GitHub issue would have a unique ID: github.com/issues/123, github.com/issues/456
• ✅ Different issues can coexist
• ✅ Fully backward compatible (falls back to url_fragment if not specified)
• ✅ Works with any use case: Jira tickets, Gmail conversations, etc.

Full proposal with examples and implementation details: docs/unique-pattern-proposal.md

Current Workaround

Unfortunately, there's no perfect workaround with the current implementation. The best approach is to not use the unique flag for GitHub issues and manually manage duplicate tabs.

Status

This is currently documented as a proposal but not yet implemented. Implementation would require:

• Schema changes (add unique_pattern field)
• Backend logic updates (use unique_pattern when available)
• UI updates (new input field in rule editor)

I'll keep this issue open to track the potential implementation of the unique_pattern solution.

[stevecalvert]

hi @sebastienfontaine, yes, that proposal sounds good. This keeps the existing functionaliy backwards compatible and makes it clear that the new unique_pattern attribute is just used to specify how the regex match group(s) from the URL matcher are organised to represent the unique URL. I'm sure this functionality would be useful for anyone who manages online tickets and gets frustrated with the proliferation of the same ticket in multiple tabs 👍