[PM-20210] Expand badge API #14801
Open
[PM-20210] Expand badge API #14801
+1,237
−241
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #14801 +/- ##
==========================================
+ Coverage 36.86% 36.91% +0.04%
==========================================
Files 3228 3237 +9
Lines 93388 93506 +118
Branches 14056 14064 +8
==========================================
+ Hits 34426 34515 +89
- Misses 57536 57565 +29
Partials 1426 1426 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
coroiu
commented
May 15, 2025
|
New Issues (3)Checkmarx found the following issues in this Pull Request
|
Patrick-Pimentel-Bitwarden
previously approved these changes
May 20, 2025
jprusik
reviewed
May 20, 2025
apps/browser/src/autofill/services/autofill-badge-updater.service.ts
Outdated
Show resolved
Hide resolved
jprusik
reviewed
May 20, 2025
apps/browser/src/autofill/services/autofill-badge-updater.service.ts
Outdated
Show resolved
Hide resolved
a26964a
Patrick-Pimentel-Bitwarden
previously approved these changes
Jun 10, 2025
…ditional-update-options
The service assumes that the first emission from the state will be an empty one and discards it (techincally it just doesn't act on it because pairwise requires a minimum two emissions). This caused issues when a service is able to update the state before the observable got a change to properly initialize. To fix this we simply force an empty emission before anything else, that way we will always react to the emission from the state provider (because that would end up being the second emission). We then use distinctUntilChanged to avoid unecessarily acting on an empty state.
|
JaredSnider-Bitwarden
approved these changes
Jun 26, 2025
|
BIT tests: |
jprusik
reviewed
Jun 27, 2025
Comment on lines
+113
to
+133
| BrowserApi.addListener(chrome.tabs.onReplaced, async (addedTabId, removedTabId) => { | ||
| const newTab = await BrowserApi.getTab(addedTabId); | ||
| if (!newTab) { | ||
| this.logService.warning( | ||
| `Tab replaced event received but new tab not found (id: ${addedTabId})`, | ||
| ); | ||
| return; | ||
| } | ||
|
|
||
| this.tabReplaced$.next({ | ||
| removedTabId, | ||
| addedTab: newTab, | ||
| }); | ||
| }); | ||
| BrowserApi.addListener(chrome.tabs.onUpdated, (_, changeInfo, tab) => { | ||
| if (changeInfo.url) { | ||
| this.tabUpdated$.next(tab); | ||
| } | ||
| }); | ||
| BrowserApi.addListener(chrome.tabs.onRemoved, (tabId, _) => this.tabRemoved$.next(tabId)); | ||
| } |
There was a problem hiding this comment.
hrm; is adding parallel listeners to the tab going to increase overhead/affect performance? Certainly cleaner code-wise, just wondering if we'd run into issues implementing this pattern for other tab event side-effects
jprusik
approved these changes
Jun 27, 2025
JaredSnider-Bitwarden
approved these changes
Jun 30, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎟️ Tracking
📔 Objective
🆕 Updates
The previous implementation didn't handle tab ids which resulted in a bug where some separate windows which were actually interpreted as tabs by the browser caused the badge autofill number to disappear. An example of this is if you opened the Bitwarden popout:
The
BadgeServicenow has full support for tabs meaning that you can now set tab-specific badge states. The autofill implementation has been completely rewritten to take advantage of this.In comparison to the old
badge-listenerthe newBadgeServicedoes not need to be updated every time the user changes active tabs, instead the browser will keep track of all states for us and automatically change the badge whenever a different tab is displayed. This means that the newBadgeServicewill not have to wake the service worker for active tab changes.📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes