Issue with code blocks for 1Password users

tips & tricks
1

If you include code blocks in your Hugo posts, those who are using the current version of the 1Password browser extension may find the code blocks unreadable because of a glitch in the extension (its injected.js script is adding syntax highlighting of its own that doesn’t work well with how Hugo and Chroma operate). Related discussion here. For now, I am using the following in my posts’ single.html layout to alert readers accordingly (example here), and you may want to do something similar:

{{- if (findRE `<div class="highlight"` .Content 1) -}}
<p class="box"><strong class="red">Important note, 2025-12-26</strong>: If you’re viewing this with the <strong><a href="https://1password.com">1Password</a> extension</strong> activated in your browser, any code blocks contained in this site (<a href="https://www.1password.community/discussions/developers/1password-chrome-extension-is-incorrectly-manipulating--blocks/165639">and others</a>) may look strange to you and may even be unreadable.<br />
&nbsp;<br />
Until you’re running a <strong>fixed</strong> version of the extension (not yet available as of <span class="nobrk">2025-12-26</span>), the only solution is to disable the 1Password extension while reading the code blocks. I apologize for whatever inconvenience this may cause in the interim. Let’s hope the folks at 1Password resolve it soon.</p>
<p>&nbsp;</p>
{{- end }}

(Your CSS styles will vary, of course.)

1 Like
2

Ah, the good old “we save you from yourself by breaking the thing you might use wrong” defense…

Does data-1p-ignore as attribute/property (no value needed) do anything? That is their “official” way to mark input fields as “do not check”. Maybe it works on code sections too? Maybe put it on the div around your code section via a renderhook?

1 Like
3

Does data-1p-ignore as attribute/property (no value needed) do anything? That is their “official” way to mark input fields as “do not check”. Maybe it works on code sections too? Maybe put it on the div around your code section via a renderhook?

As nearly as I can tell in local production-mode testing — as well as trying it with the Blink Inspector’s Edit as HTML capability in another site’s affected page — the answer appears to be that data-1p-ignore doesn’t resolve this. Of course, I am happy to be proven wrong if anyone has different results. In any event, thanks for that helpful suggestion, which may well be useful for other situations involving interaction between 1Password and one’s Hugo site(s).

4

For those wondering, here’s an example of what the 1Password bug does to anything from the combination of Hugo and Chroma.

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>
5

Also, a Redditor suggested a fix using the render hook, á la what @davidsneighbour mentioned:

{{- $lang := .Type -}}
{{- $code := .Inner -}}
{{- $options := dict "lineNos" true "style" "github-dark" -}}
{{- if $lang -}}
{{- $highlighted := transform.Highlight $code $lang $options -}}
{{- /* Replace language- with syntax- to avoid 1Password selector */ -}}
{{- $highlighted = replace $highlighted (printf "language-%s" $lang) (printf "syntax-%s" $lang) -}}
{{- $highlighted | safeHTML -}}
{{- else -}}
{{- /* For code blocks without language specified */ -}}
<pre><code>{{- $code -}}</code></pre>

{{- end -}}

Styling is based on the Redditor’s theme.

6

https://x.com/search?q=conversation_id%3A2005904473332564339&src=recent_search_click&f=live

They’re positioning themselves for an IPO in 2026, with several C-level changes and a focus on AI. It’s not surprising, at least to me, that a browser extension got lost in the noise.

I sent a “heads up” to the CEO earlier today.

Bitwarden’s a great alternative.

1 Like
7

It definitely is, and I’ve used it, too (as well as KeePassXC, for that matter). While Bitwarden’s browser extension also injects some JS, it’s been less problematic; at least, I have never heard of its having injected “rogue” formatting in this fashion.

1 Like
8

Follow up: I've created an incident internally. The fix has already been merged into our main branch. We'll be putting out a release with just this fix. I'm hoping to have it submitted to the browser extension stores today.

— Robert Menke (@RobertBMenke) December 30, 2025
3 Likes
9

Here’s the latest on the 1Password extension SNAFU from The Horse’s Mouth (or, more accurately, Horses’ Mouths, since we are talking about a development team), confirming that it will be days before a fix gets to the world at large:

10

Update, 2026-01-01: the 1Password extension for Chrome has now been updated to v.8.11.27.2, which fixes this bug. No relevant updates yet for Firefox or Safari.

2 Likes
11

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.