还有人坚持用 1Password 6 吗？我把 1password chrome classic 扩展改成 MV3 了

不错

自己搭建更香 Bitwarden

@nifan 之前 1p 扩展不能用，用过一段时间的 bitwarden ，一直不习惯他的界面

1p 6 如果不是太老了 Intel Only 确实可以继续用下去

我用 Gemini 把 https://github.com/wowh/1password
和之前的代码 https://github.com/scramblr/1password 做了比对

大家可以参考一下


While they are both versions of the Stanford JavaScript Crypto Library (SJCL) and share about 99% of the same logic, Code 2 contains environment-safety modifications that are missing in Code 1.

Specifically, Code 2 has been updated to be more "environment-aware" (likely to prevent crashes in Node.js or Server-Side Rendering environments), whereas Code 1 is a more traditional browser-only minification.

Key Logical Differences
Here are the specific areas where the logic differs beyond simple formatting:

1. Environment Safety Checks (window and document)
In the sjcl.random.startCollectors and stopCollectors functions, Code 2 adds checks to see if window or document are defined before accessing them.

Code 1:

JavaScript

if(window.addEventListener){ ... }
else if(document.attachEvent){ ... }
Logic: This will throw a ReferenceError in environments like Node.js because window is not defined.

Code 2:

JavaScript

if (typeof window !== "undefined" && window.addEventListener) { ... }
else if (typeof document !== "undefined" && document.attachEvent) { ... }
Logic: This is safe. It checks the type first, so it won't crash in non-browser environments.

2. Error Handling Removal
In the startCollectors function, Code 1 has a fallback error that Code 2 has removed.

Code 1:

JavaScript

else throw new sjcl.exception.bug("can't attach event");
Code 2: The else block is entirely removed. If it can't find window or document, it simply does nothing rather than throwing an exception.

3. Stop Collectors Logic
A similar change exists in stopCollectors:

Code 1: Directly checks window.removeEventListener.

Code 2: Checks typeof window !== "undefined" before attempting to access window.removeEventListener.



While they share the same core cryptographic libraries (SJCL) and general business logic, Code 2 is a significantly modified version of Code 1, specifically updated to be compatible with Chrome Extension Manifest V3 (MV3). Code 1 is written for the older Manifest V2 (MV2) standard.

Here are the specific logical and functional differences:

1. Global Scope Reference (window vs. self)
Since Manifest V3 uses Service Workers (which do not have access to the window object), the global scope references have been changed.

Code 1: Uses window (e.g., n='undefined'!=typeof window&&window===this?this... and window.OnePassword=r).

Code 2: Uses self or globalThis (e.g., n = 'undefined' != typeof self && self.self === self ? self... and self.OnePassword = r).

2. Browser Action API
Chrome changed the "Browser Action" API to a generic "Action" API in Manifest V3.

Code 1: Uses chrome.browserAction (e.g., chrome.browserAction.onClicked... and chrome.browserAction.enable()).

Code 2: Uses chrome.action (e.g., chrome.action.onClicked... and chrome.action.enable()).

3. Navigation Interception (webRequest vs. tabs)
This is the most significant logical rewrite. Manifest V3 restricts the use of blocking webRequest.

Code 1: Uses chrome.webRequest.onBeforeRequest with the ['blocking'] attribute to intercept URLs containing onepasswdfill.

Code 2: Completely removes the webRequest logic and replaces it with a chrome.tabs.onUpdated listener. It now watches for tab updates to detect those specific URLs instead of intercepting the network request.

4. Context Menus Implementation
Code 1: Uses the onclick property directly inside the chrome.contextMenus.create object.

Code 2: Removes the onclick property from the creation object (as it's forbidden in MV3) and implements a centralized listener using chrome.contextMenus.onClicked.addListener. It also adds a mandatory id to the menu item.

5. URL API Modernization
Code 1: Accesses the URL constructor via window.URL || window.webkitURL.

Code 2: Accesses it via globalThis.URL || URL.

和官网原始版本（ 6.8.9 ）最大的不同就是现在完全不需要输入 master 密码解锁
Alfred launch 后直接就解锁了🔓

不知道有其他大佬也是这样的情况吗😄😄

@hackpro 是不是 1password 本身就是解锁状态？我这边测试没这个问题，还是需要解锁才能使用

@wowh 感谢老哥
我测了手头俩台设备 好像只有 M 系列才有这个问题 intel 10.15 没问题🤣

@hackpro 手头没 m 系列的 mac ，扩展管理检查视图，背景页点进去看下 console 里的 log 是否有异常

@wowh 老哥顺便请教下你的 1p mini 浏览器小窗口也是 dark 背景吗
我记得原版的好像不是这样还是脚本改了什么东西 每次扒拉账号信息看起来好吃力😄

@hackpro 我试了下旧版也是这样的，系统如果是深色的就会跟随深色背景 intel mac sequoia 15.7.2 系统

@wowh 问题是我系统设置的是 light theme
1p 主程序打开也是 light 但是 chrome 插件也 dark theme🤣

@hackpro 是什么系统啊，有点奇怪啊，我看了下这个界面是 1password mini 直接输出的，没法在扩展里面修改

@wowh
* macOS 15.1 light theme, 1p 6.8.9 主程序 light theme, 1p mini extension dark
* macOS 10.15 light theme, 1p 6.8.9 主程序 light theme, 1p mini extension light

https://imgur.com/a/zhTyhfe