Safari support

[richardkmichael]

Investigate Safari browser extension compatibility.

Safari uses WebExtensions API but has some differences from Chrome/Firefox.

Tasks:

• Research Safari Web Extension requirements
• Determine manifest compatibility
• Test basic functionality
• Document any limitations

[richardkmichael]

Safari Support Investigation

Investigation into Safari browser extension compatibility for github-bookmarked-issues.

Summary

Safari support is feasible with minimal code changes. The main limitation is that Safari (MV3) doesn't support webRequest API, which the extension uses only for optional hash discovery - not core functionality.

Data Fetching Architecture

The extension has TWO data fetching paths in content-issues-list.js:

1. GraphQL (Primary) - Lines 92-142

// Uses hardcoded query hashes (lines 19-35)
const GITHUB_QUERIES = {
  issueDashboard: { hash: 'e02318ebeb8613553613ac1ebdbb7a4b', ... },
  issueRowSecondary: { hash: 'c5aa81956ee8f848ea72a183fef833c9', ... }
};

• Batch fetches ALL bookmarks in just 2 requests
• Uses GitHub's internal /_graphql endpoint with persisted queries
• If hardcoded hashes expire, attempts discovery via webRequest (lines 66-86)

2. REST API (Fallback) - Lines 1033-1047

// Falls back to individual REST API calls per bookmark
const issuePromises = bookmarkArray.map(bookmark =>
  fetchIssueDetails(bookmark.owner, bookmark.repo, bookmark.number)
);

• One API request per bookmark via https://api.github.com/repos/{owner}/{repo}/issues/{number}
• Subject to rate limiting (60/hour unauthenticated, 5000/hour with PAT)

webRequest API Role

The webRequest.onHeadersReceived listener (background.js:72-108) is used ONLY for hash discovery when hardcoded hashes expire - not for primary operation.

Safari Impact Assessment

Scenario	Safari Behavior
Hardcoded hashes valid	GraphQL works normally
Hardcoded hashes expire	No auto-discovery, falls back to REST API
REST API fallback	Works (one request per bookmark)

Safari limitations:

• Cannot discover new hashes when GitHub changes them
• Would need manual extension updates to refresh hashes
• REST API fallback is slower (N requests vs 2) and has rate limits

API Compatibility

API	Safari Support	Notes
storage.sync	Yes	Works normally
storage.local	Yes	Works normally
runtime.sendMessage	Yes	Works normally
runtime.onMessage	Yes	Works normally
webRequest.onHeadersReceived	NO	MV3 incompatible
fetch()	Yes	Web API, not extension API
DOM APIs	Yes	Standard web APIs

Implementation Requirements (If Proceeding)

Build System Changes

1. Create manifest-safari.json (MV3, service worker based)
2. Add Safari build target to scripts/copy.js
3. Update scripts/build.js for Safari output
4. Conditionally skip webRequest listener registration
5. Safari requires Xcode project wrapper for distribution

Development Requirements

• macOS with Xcode required
• Safari > Settings > Advanced > "Show Develop menu"
• Develop > "Allow Unsigned Extensions" for testing
• Apple Developer Program ($99/year) for App Store distribution

Decision Points

1. Is Safari worth supporting given the hash discovery limitation?
   • GraphQL still works (hardcoded hashes)
   • Graceful REST fallback when hashes expire
2. Is the Apple Developer Program cost ($99/year) justified?
3. Should Safari be first-class or community-contributed?

Sources

• Apple: Assessing Browser Compatibility
• MDN: Safari dropped webRequest in MV3
• W3C: webRequest API alignment issues
• Apple Developer Forums: webRequest API on Safari
• MDN: Build cross-browser extension