1Password Chrome extension is incorrectly manipulating <code> blocks | 1Password Community

7 min read Original article ↗

Forum Discussion

joeRinehart's avatar

Solved

The latest 1Password Chrome extension is incorrectly manipulating the DOM within <code> blocks on static pages. It looks it's using prism.js to try to add syntax highlighting to <code> blocks on the entire page. If you're using a static site generator to highlight code with a different library, it causes the display to break.

Example: mkdocs, a popular documentation tool

If you view the documentation for customizing Mkdocs material (https://squidfunk.github.io/mkdocs-material/customization/) with the extension enabled, you'll see that the YAML example at the top is not highlighted (it should be). 

Under the hood, if you inspect its DOM, you can see that it's been rewritten with prismjs classes.

If you disable the extension, it is highlighted:

This is likely to impact a number of documentation sites in the tech community.

  • 1P_Blake's avatar

    Hey everyone! I want to thank everyone who called our attention to this and explain what happened and what we’re doing about it.

    What happened: Prism.js is a syntax-highlighting library we use for our Labs Snippets feature. While optimizing our build to reduce bundle size, we unintentionally bundled Prism.js into the extension in a way that caused it to run on pages where it shouldn’t, which interfered with code formatting on certain sites. We apologize for the inconvenience this caused.

    What we’re doing about it:  We’ve completed the fix and submitted it to the Chrome Web Store, along with Firefox, Edge, and our other supported extension storefronts. Rollout timing depends on each store’s review process, but we expect it to land over the next few days.

    We want to emphasize that vault security was not impacted. At 1Password, protecting our customers’ privacy, passwords, and credentials is our highest priority.

    We’ll be publishing a postmortem covering what went wrong, the timeline, and the concrete changes we’re making to how we build and release future browser extension updates.

50 Replies

  • joesward's avatar

    I'm really not sure why Re: Has something changed: http:// not filling in any more? has been merged into this discussion, as this seems like a completely different issue.   This update has not solved anything  -  I am still unable to use 1Password on local http:// sites.  Using version 8.11.27.2, (Chrome, Mac) I am still unable to use 1Password to fill/auto fill, same error in console: 

    Failed to fetch chrome-extension://aeblfdkhhhdcdjpifhhbdiojplfjncoa/inline/injected.js, Import failed 3 times. Final error: window.crypto.randomUUID is not a function"

    1P_Blake​ can you please let us know when this issue will be solved?

    Thanks!

  • 1P_Blake's avatar

    Hey everyone! I want to thank everyone who called our attention to this and explain what happened and what we’re doing about it.

    What happened: Prism.js is a syntax-highlighting library we use for our Labs Snippets feature. While optimizing our build to reduce bundle size, we unintentionally bundled Prism.js into the extension in a way that caused it to run on pages where it shouldn’t, which interfered with code formatting on certain sites. We apologize for the inconvenience this caused.

    What we’re doing about it:  We’ve completed the fix and submitted it to the Chrome Web Store, along with Firefox, Edge, and our other supported extension storefronts. Rollout timing depends on each store’s review process, but we expect it to land over the next few days.

    We want to emphasize that vault security was not impacted. At 1Password, protecting our customers’ privacy, passwords, and credentials is our highest priority.

    We’ll be publishing a postmortem covering what went wrong, the timeline, and the concrete changes we’re making to how we build and release future browser extension updates.

    • elbart's avatar

      1P_Blake​ Thank for giving us an update here and the explanation. Thanks to the team for taking care of this!

      Can you please let us know:
      1. Which version numbers contain the fix for the various storefronts?
      2. Is the fix already rolled out in the nightly builds?

      Thanks and kind regards,

      Tim

      • 1P_Blake's avatar

  • ragnar14's avatar

    This is breaking documentation on Microsoft Learn docs site https://learn.microsoft.com/en-us/dotnet/core/deploying/ready-to-run

    It's been broken for months and I was frustrated thinking Microsoft either did this intentionally or was negligent in fixing a bug they caused that ruined their entire docs website.

    What they're supposed to look like:

    What 1Password does to them:

  • BryceWray's avatar

    Looks like we’re getting closer to a fix being released; also appears that Evan You (the Vue guy) was bitten by this bug, too. See this thread on X (my original text had a link to the xcancel.com version, but the mods changed it to what you see below):

    https://x.com/youyuxi/status/2005904473332564339?s=20

  • schneidro's avatar

    This issue also breaks default syntax highlighting for Antora/Asciidoctor. I suspect that the majority of AsciiDoc-based websites are now rendering with broken syntax highlighting for any user with the 1Password extension installed in their browser.

    For example, all of these sites are actively affected:

    • DataStax Docs: https://docs.datastax.com/en/astra-db-serverless/get-started/quickstart.html#connect-to-your-database
    • Couchbase Docs: https://docs.couchbase.com/python-sdk/current/hello-world/start-using-sdk.html#hello-couchbase
    • Quarkus Docs: https://quarkus.io/guides/getting-started#bootstrapping-the-project
    • Spring Security Docs: https://docs.spring.io/spring-security/reference/servlet/getting-started.html
    • MuleSoft Docs: https://docs.mulesoft.com/mule-sdk/latest/notifications
  • imgggg's avatar

    Been using 1Password for at least 6yrs. I'm absolutely pissed off after hours of debugging on why code highlighting does not work anymore. Been trusting the extension despite there was some hiccups before so ironically a browser extension of a password manager is the LAST thing came to my mind to check.

    How many people would this update break?

    This is one of the changes that should guard against a feature flag with gradual rollout. Why it is not is beyond me.

    HOW DOES THIS EVEN GET TO PRODUCTION IN THE FIRST PLACE?

    ---

    Edit: Can confirm that iOS 1Password Safari Extension also breaks. I bet they're using the same codebase.

    This is severe to the point where this is not a regular hiccup anymore. This breaks OTHER'S site without any clue on how they're suppose to fix YOUR issue. If this does not get fixed people's codebase would literally starting to have "# Dirty fix for a nasty 1Password bug".

    Please take more attention to this and fix it ASAP. This is the most severe incident I can consider that a browser extension could cause.

  • paulk's avatar

    1P_Blake​ In the future, please do some user acceptance testing before releasing a new version of the extension globally.

  • benjvogt's avatar

    I am experiencing this issue and it wildly inexcusable. Why is 1password interfering with the normal rendering of non-login, non-html-form related layouts and features?

    • BryceWray's avatar

      Here’s an example of what the bug does to anything from the combination of the Hugo static site generator and its Chroma dependency for syntax highlighting.

      This is a code block on one of my Hugo-generated pages with 1Password disabled:

      <div>
        <div class="highlight">
          <pre tabindex="0" class="chroma">
            <code class="language-plaintext" data-lang="plaintext">
              <span class="line">
                <span class="cl">
                  /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo
                </span>
              </span>
            </code>
          </pre>
        </div>
      </div>

      ...and this is the same code block with 1Password enabled :

      <div>
        <div class="highlight">
          <pre tabindex="0" class="chroma language-plaintext">
            <code class="language-plaintext" data-lang="plaintext">
              /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo
            </code>
          </pre>
        </div>
      </div>
  • ponaj39356's avatar

    The extension injects a script (injected.js) that calls highlightAllUnder(). The script then uses innerHTML on the matched code elements, mutating the host page DOM after hydration and interfering with existing syntax highlighters.

    As a result, all code blocks matching the following selectors are re-highlighted:

    code[class*="language-"], [class*="language-"] code, code[class*="lang-"], [class*="lang-"] code

    These selectors target all <code> elements that are marked for syntax highlighting by matching either language-* or lang-* classes, whether the class is applied directly to the <code> element or to one of its parent containers

    • wjoell's avatar

      Does beg the question once again: why is 1P injecting anything that manipulates code blocks?

    • rhukster's avatar

      yah my PHP code basically removes all the language- / lang- references from code blocks. I don't need them as i'm using a server-side rendered syntax highlighting, but it was there for github support etc. 

  • hachi8833's avatar

    I encountered exactly the same issue. 1Password Chrome extension surely breaks our WordPress blogposts' CSS styling:

    Note that the boxes are incorrect and are not what we want.

    When disabling the extension, all works fine:


    It is strange that no differences between the HTML sources. 

Featured discussions

Recent discussions

  • samroberts's avatar