bootstrap-content-message-handler.js prints to browser console on every window message, even those made by other extensions

[OneNot]

Steps To Reproduce

Example of when the issue would happen: Using both this addon and Bitwarden's Firefox addon and navigating to youtube.com, the browser console gets flooded with constant debug messages.

Expected Result

bootstrap-content-message-handler.js should probably only log messages that originate from Bitwarden's own scripts.

Actual Result

bootstrap-content-message-handler.js floods the console with debug messages for every window message made by any addon.

Screenshots or Videos

No response

Additional Context

Anything that uses window messages is caught by Bitwarden's bootstrap-content-message-handler.js. As an example navigating to youtube.com with this addon and Bitwarden's addon enabled, the console gets constantly spammed with these two debug messages:

Handling window message [bootstrap-content-message-handler.js:167:21](moz-extension://ab53cc0e-d7fc-4dfe-8d84-71c9e7ffc4e0/content/bootstrap-content-message-handler.js)
Bad source or badly formatted message, skipping. [bootstrap-content-message-handler.js:171:25](moz-extension://ab53cc0e-d7fc-4dfe-8d84-71c9e7ffc4e0/content/bootstrap-content-message-handler.js)

by Bitwarden's bootstrap-content-message-handler.js

I only marked Windows 11 and Firefox in the issue template as that was where I saw the issue, but I assume the issue isn't exclusive to either.

Operating System

Windows

Operating System Version

11

Web Browser

Firefox

Browser Version

121.0.1

Build Version

2024.1.0

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[freelock]

Same issue in Firefox Linux -- and others are saying it also affects Chrome, Mac, everywhere - https://community.bitwarden.com/t/looping-infinitely-bootstrap-content-message-handler-js-is-looping-infinitely-on-almost-every-website/62270

[Neonwarden]

Hi there,

Thank you for your report!

I have flagged this to our engineering team.

If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time - our engineering team will be happy to review these.

Thanks once again!

[hkbertoson]

I turned off every other extension that I have and only had Bitwarden running. Not even logged in and it seems like anything I do triggers this error message.

https://github.com/bitwarden/clients/assets/44106297/18f01e30-c640-4ea1-b0f0-09d9f0d6b701

[grafficmedia]

As a web dev, this is an extremely annoying bug, as it clogs up my console which I need in order to do my job. I will most likely have to uninstall the extension if this is not resolved promptly.

[oliver139]

This is super URGENT to be fixed. As said on above, it is highly affecting web dev to do their job. MacOS with Firefox here

https://github.com/bitwarden/clients/assets/45283723/b3b9f8ce-e695-4ddf-98b3-c2f060535f8e

[oliver139]

For those who are not working on React project, please try to disable the React Dev Tools. It stops looping the message on my machine.

And because it is using console.debug to log the message, you can also filter away them and meanwhile avoid using console.debug in yout project.

[DJDavid98]

I happen to be working on a React app and use Debug logs specifically because the other types tend to be clogged up, this is an extremely disrupting issue.

[pensono]

This issue isn't related to react, I've found the same thing in a Svelte project.

As a workaround, enter the following string into the filter box of your console to filter out the messages: -/Bad source or badly formatted message, skipping|Handling window message/

[tfilo]

I have this issue as well with Firefox plugin. Console full of this messages, it really make development of web apps really hard. Hope it will be fixed soon. For now I am disabling this plugin.

[mean-cj]

Google Chrome Windows 10 / Version 120.0.6099.217 (Official Build) (64-bit)

Same Issue

[alike03]

For people who need the console, a temporary solution is to disable debug logging on Firefox. You will still get errors, warnings, logs and info.

[jan-paulus]

I'm having the same issue in Brave Version 1.61.116 Chromium: 120.0.6099.217 (Official Build) (arm64)

[reduckted]

If you follow the link in the browser console that takes you to the source of the console statement, it shows the source as:

    init() {
        // eslint-disable-next-line no-console -- In content script
        console.debug("Attaching message event listener.");
        window.addEventListener("message", this.handleWindowMessage, false);
        chrome.runtime.onMessage.addListener(this.handleExtensionMessage);
    }

That doesn't match what was committed to this repository: https://github.com/bitwarden/clients/blob/5906a3633554206e6e17e5b93beb9c7585605384/apps/browser/src/autofill/content/content-message-handler.ts#L16-L19

Is the extension not being built from the committed code? That seems less than ideal.

[rcursaru]

same behaviour on Fedora 39/Firefox 121.0.1

[Devconte]

Same behaviour on Firefox 121.0.1 (64 bits), as suggested in this topic on bitwarden forum, i disabled React Dev Tools and no more spam error in console.

[schulzjona]

https://github.com/bitwarden/clients/commit/e8a54a70a5d136d4e0d7ccdb15d5056d681c3f47

Seems to be related to this commit/release

Happening everytime anything uses window.postMessage

[justindbaur]

Hey folks! We apologize for the flood of logging. That logging was added to our release candidate code to help pin down an issue that was very intermittent. The logging is not in main and therefore will not be included in the next release which is slated to start February 7th. The logs are in the debug channel so if able, you can disable the Debug/Verbose channel, which is off by default in chrome. If you still need debug logs here are a few suggestions:

The filter provided by @pensono is a good one. -/Bad source or badly formatted message, skipping|Handling window message/.

My personal recommendation is to use a different browser/profile to develop in separate from your personal extensions/data. This allows me access to newer chrome API's since I use Chrome Canary to develop vs Firefox personally. It also means I can enable all the other developer goodies in chrome://flags that I wouldn't want on normally. It also means I can close and reopen chrome with different command line arguments like my personal fave --auto-open-devtools-for-tabs.

If the logs you care about come from an iframe by chance you can change your devtools to only show messages from that context. In firefox that is done by clicking Top at the far right of the console input line and switching contexts.

Or in chrome that same button in at the top of the console tab.

[Xanax-C-137]

Everyone using Chromium-based browsers should be able to right-click and select "Hide messages from bootstrap-content-message-handler.js" for now.

[VAggrippino]

Hey folks! We apologize for the flood of logging. That logging was added to our release candidate code to help pin down an issue that was very intermittent. The logging is not in main and therefore will not be included in the next release which is slated to start February 7th.

I just want to make sure I understand...

1. Was this issue from a release candidate that was pushed to the official extensions sites for both Chrome and Firefox?
2. This won't be corrected until the next full release on February 7th?

I have no problem with either of these details. Like I said, I'm just tryin' to make sure I understand.

[nook24]

Same for me on Firefox on Windows. I had to disabled Bitwarden from Firefox so I can work again

// Edit

If I disable the Angular DevTools the error also disappears

[DJDavid98]

With all due respect, fixing this shouldn't take ~3 weeks, and a change like this should really be behind some kind of feature flag that the person testing the extension can enable for themselves, not on by default.

If this is the current situation and it's expected to be handled as described, please use this as a learning opportunity how not to do this in the future.

[robbyphillips]

Hey folks! We apologize for the flood of logging. That logging was added to our release candidate code to help pin down an issue that was very intermittent.

Sorry, but how does filling my console help you debug this issue?

Why was this version pushed out to everyone if it's only a release candidate, not a mainline release?

[daveidivide]

Another react dev here with the issue on Firefox.

I can't find how to permanently hide these messages on Firefox so I've found that filtering by -hand hides them for me.

[szamanr]

workaround

you can temporarily install an older version of the extension.

firefox

1. find one here: https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/versions/?utm_content=search&utm_medium=referral&utm_source=addons.mozilla.org
2. download the file
3. run it, which will install and overwrite the current version
4. make sure to disable automatic updates for bitwarden extension, otherwise it will revert to the latest version on next browser restart

remember to re-enable updates once the issue is fixed.

chrome

unsure - can someone comment?

---

PS. it's not ok to release something like this publicly. as said before, this should be hidden behind a feature flag or not widely released. please update your release workflow. cc @justindbaur

[vad99lord]

Possible to introduce a flag in the options section of the extension? Something like enable logs. So we can easily turn it off, and debugging still will be available? Really annoying thing, since I'm using logs filtering for personal purposes

[ragnese]

With all due respect, fixing this shouldn't take ~3 weeks, and a change like this should really be behind some kind of feature flag that the person testing the extension can enable for themselves, not on by default.

If this is the current situation and it's expected to be handled as described, please use this as a learning opportunity how not to do this in the future.

@justindbaur, I agree with @DJDavid98 that this isn't the kind of thing that should wait until the next normal release. This is a bug that is quite frustrating for the users who notice it and as such should warrant a bugfix release ASAP.

I know you're being flooded right now because of this issue (which is also a hint that it needs to be fixed ASAP), but I do want to say that I'm a huge fan of Bitwarden and appreciate your hard work.

[justindbaur]

Hi All, I am not the one that makes the go/no-go call on a release but I can assure you the people who do are aware of this issue and the comments you are making. It's not off the table but as of now we aren't planning on another release for this.

As far as a feature flag for this, we do use feature flags for various things but it would not have been the place for this particular issue. We were dealing with a race condition of a message being sent before the listener was ready for it. Anything that tampered with those timings would have made the logging moot.

This will not be a regular thing for us, we pretty sparingly use logging and especially don't generally use it in any content scripts but the specifics around this issue called for it. There are extra headaches around packaging and deploying a safari browser extension that I made the call that I needed logs in the hands of our QA people to help me figure out an issue. We try to very minimally change our release candidate code between the time it's cut and our release and we extra don't want to change it between the time QA has finished testing and release. That is why the logging didn't get reverted.

[robbyphillips]

We try to very minimally change our release candidate code between the time it's cut and our release

What is the difference between a release candidate and the mainline release if they are both distributed by the main channel?

Edit: @justindbaur, Apologies if this came across as too pointed. I'm trying to understand the process here because I really like BitWarden and trust it with a lot of important information. Obviously this is an issue with pretty straightforward workarounds, and it will likely only affect users who know what to do about it. However, it also seems like something that should not have been widely distributed and reading your comments, I'm genuinely confused about what your release process is.

[grafficmedia]

Something really isn't adding up here. If this change isn't in your main branch, how did it get pushed out to the extension store and into all of our hands? Agree with @robbyphillips, have run a few release processes myself and this one really has me scratching my head.

Clarity on this issue is going to be necessary to quell my nerves about using this product, to be honest. If y'all are just releasing code into the wild that shouldn't be, that seems like a pretty major security risk.

[nook24]

Hey folks! We apologize for the flood of logging. That logging was added to our release candidate code to help pin down an issue that was very intermittent. The logging is not in main and therefore will not be included in the next release which is slated to start February 7th. The logs are in the debug channel so if able, you can disable the Debug/Verbose channel, which is off by default in chrome.

I use Bitwarden with Firefox on Windows. I never switched to a beta channel or anything like that. Honestly I don't even find a switch in the settings of the extension to do so. The issue is within the current version you get, if you install the Bitwarden extension from the Mozilla Addons page. (Version 2024.1.0)

Hope this helps

[hugoattal]

@robbyphillips @grafficmedia @nook24 Here's the timing of the events to my understanding

• Logs are introduced to debug some race conditions
• ~The release candidate of 2024.1 is fixed and QA start testing it~
• ~The logs get removed in the dev version, but they don't want to push it on the release candidate as testing has already started~
• They shipped this current version (2024.1) with the logs as main
• ~The dev version with log removal gets moved to release candidate~
• They will ship the next release candidate as main (v2024.2)

(Good luck with everything to the BitWarden Team)

EDIT: see message below ⬇️

[justindbaur]

We are constantly developing and pushing code to main. When we are preparing for release we create a branch called rc. From that point on, that branch is only to be updated with the express approval of our QA, essentially only critical bug fixes. We were encountering what we consider a release blocking bug where our SSO flow in our Safari browser extension was not working. I spent hours trying to recreate the issue but was unable to. In a desperation attempt I requested, internally (to my manager, our QA team, and our devops team), approval to cherry pick a commit adding only logging to rc. That commit can be found here. It was decided to do it there because we didn't want it in main and to become a regular part of our code.

We knew the logging would be in released code, my manager asked me if it would be okay to release and I said yes it would be fine to release since we don't actually log any of the payloads of any message sent through the window messaging API, which I would have considered an issue. I admittedly underestimated the differing extensions that heavily utilize window.postMessage on websites and how many people utilize the debug channel of logs in dev tools.

[daveidivide]

Thanks for the explanation @justindbaur.

I'm sure 99% of users have no idea about this. Obviously it's all devs here that work in the console regularly. (Why else would other users be on GitHub anyway).

But yeah, turns out we get pretty irate when you mess with our console logs 🤣

Perhaps one day we'll learn to use proper debugging tools, instead of the console. But not today haha

[nook24]

Many thanks for your feedback @justindbaur

I guess everything was said, the devs are aware of the issue so we can wait for a fix and just filter the message for now.

Thanks for your hard work!

[grafficmedia]

Thank you for explaining how this issue ended up in production. Confidence restored.

[juanozorio]

I have the "React Dev Tools" extension, I disabled it and reloaded the page, and it stopped having the "console.log" flood.

Thanks, @oliver139

[htr3n]

+1 with this issue on Firefox and Chrome. Disabling React Developer Tools stops the messages.

[viniciuspc]

I need to use the React Developer Tools so I disabled bitwarden plugin instead

[jfvillablanca]

+1 on Firefox Developer Edition. Thanks for the explanation

[noc2spam]

Daaaang... I totally thought my code was doing it, at first. LOL. Please remove the message as soon as you can guys. Its pretty annoying. :(

[leonardoboch]

It also happens with Vue Dev Tools.

[hichxm]

Same here with Laravel project (TALL stack)

[sneakers-the-rat]

I'm still trying to understand this:

I spent hours trying to recreate the issue but was unable to. In a desperation attempt I requested, internally (to my manager, our QA team, and our devops team), approval to cherry pick a commit adding only logging to rc. That commit can be found here. It was decided to do it there because we didn't want it in main and to become a regular part of our code.

so because a bug couldn't be recreated in the dev environment, the goal was to deploy something with the logging so that when the bug appeared in the wild you could collect the logs? am I reading that right? and adding that resolved the release-blocking bug? I am just not sure I understand the reasoning there.

I also get that QA is a thing, but don't understand why it's impossible to push an update that just removes those debug log calls until the next release.

Ordinarily I wouldn't care but since this is a password manager, sloppy dev practices (not blaming you, i get you're just trying to make something work and don't run the whole show) make me nervous, and i'm trying to understand what exactly broke down here and why a fix isn't forthcoming.

[saevarb]

@justindbaur

It's great that you have your own preferred way of developing with a separate profile and whatnot, but that seems like a rather poor argument to justify flooding the logs with messages because it doesn't bother you.

I experienced some pretty serious performance degradation due to these logs and had to restart the browser (this was before I knew which extension was the culprit). I also happen to use debug logs and rather frequently use the filter functionality of the console, the react dev tools and my password manager, to, you know, log in to stuff.

What is the best way to install a version of the extension that doesn't suffer from this issue? Providing a way to actually fix this issue -- not just get around it using your own preferred methods of doing whatever -- seems like the least thing you folks could do here.

[ronyclau]

Not sure about other browsers. If you are using Firefox, you can installed a previous version here: https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/versions/

You may need to downgrade again when auto-update kicks in, or disable auto-update (NOT RECOMMENDED) for the time being.

[lil5]

@justindbaur Next time you try this, make it check if you have debug flag enabled for bitwarden on a localstorage kv. The argument that it needed to be in RC thus it was in Production is confusing.

Best of luck with Apple SSO!

[oliver139]

Daaaang... I totally thought my code was doing it, at first. LOL. Please remove the message as soon as you can guys. Its pretty annoying. :(

Me too LOL Especially I am working on a bootstrap project

[JannesMeyer]

Downgrade instructions for Firefox

1. Go to addons.mozilla.org, look for version 2023.12.1 and click "Download file":

   

2. After the download finishes click on "Add":

   

3. Go to the extension settings and disable automatic updates:

   

4. Remember to enable automatic updates again when the next version is released

[MidnightTinge]

when you get to the point people are suggesting to downgrade and disable auto updates I really do gotta question some of the logic being thrown around to justify not reverting. I love the tool, but this makes me question whether or not I trust updates in the future to not disrupt my daily flow. the fact that this wasn't even considered to be put behind a flag is weird, doubly so considering this is in an "RC" that somehow got pushed out to the general public? or maybe I missed some context there.

regardless, the fact that this won't be disabled until February is incredibly annoying, especially for a tool that I'm paying for. my options are to either disable bitwarden, disable my framework's devtools, or downgrade and disable updates. none of those are appealing options.

[schulzjona]

when you get to the point people are suggesting to downgrade and disable auto updates I really do gotta question some of the logic being thrown around to justify not reverting. I love the tool, but this makes me question whether or not I trust updates in the future to not disrupt my daily flow. the fact that this wasn't even considered to be put behind a flag is weird, doubly so considering this is in an "RC" that somehow got pushed out to the general public? or maybe I missed some context there.

regardless, the fact that this won't be disabled until February is incredibly annoying, especially for a tool that I'm paying for. my options are to either disable bitwarden, disable my framework's devtools, or downgrade and disable updates. none of those are appealing options.

Filtering is not an option for you?

https://github.com/bitwarden/clients/issues/7575#issuecomment-1894963482