On 04/10/2024 13:28, woxxom wrote:
> It is indeed incompletely promisifed, see
https://crbug.com/40154924 and
> the API definition in the source code
> <
https://crsrc.org/chrome/common/extensions/api/context_menus.json;l=206;drc=218bd5b76c310d025dc4d9dff6feb4a799117a45>,
> which is yet another known bug in MV3 that's not being fixed even
> though MV2 is already getting disabled.
Return value of contextMenus.create is an excuse to some extent that it
is not converted to Promise. However I do not like discrepancy with
Firefox what exceptions are thrown synchronously. Subtle differences are
not friendly to feature detection code like in
<
https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/#event-driven-background-scripts>
Perhaps adding a new method is better than modifying `create`
<
https://github.com/w3c/webextensions/issues/312>
"[contextMenus] create or update contextMenus in a single call"
For simple cases (extension update) docs should clearly suggest
`contextMenus.removeAll()` and recreate items from scratch.
> * chrome.contextMenus.update() and remove() return a Promise in MV3
> and you'll see it if you remove "await", but .catch() on this
> promise doesn't work, meaning the API is promisified incorrectly.
> You can report it in
https://crbug.com. Meanwhile either use a
> callback and promisify it yourself or simply check
> chrome.runtime.lastError explicitly after "await".
I have noticed that `update` does not reject promises after I decided
that I can drop promisify polyfill in mv3. It is disappointing (C++ has
std::broken_promise...).
To be fair, I have not managed to get error in any form (exception,
rejected promise, runtime.lastError) from `update` and `remove` in
Firefox 115 ESR and 128 ESR. I have tried `browser` and `chrome`,
`contextMenus` and `menus`.
Actual reason why I had `contextMenus.update` is that I noticed warnings
concerning missed runtime.onInstalled event in some obscure cases
related to update in disabled state or incognito windows. Perhaps it has
been fixed. So expectation was that `update` error means wiped menu
entries. A workaround appeared to be more fragile.
Behavior of `tabs` methods is correct from my point of view
chrome.tabs.reload(123).catch(ex => console.log("ex async", ex))
Promise {<pending>}
ex async Error: No tab with id: 123.
chrome.contextMenus.remove(123).catch(ex => console.log("ex async", ex))
Promise {<pending>}
Unchecked runtime.lastError: Cannot find menu item with id 123
At first glance error handling is similar
<
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/extensions/api/tabs/tabs_api.cc;l=1907>
<
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/extensions/api/context_menus/context_menus_api.cc;l=88>
As to filing a bug, I hate pressure to provide a video for an issue that
may be described with a dozen of lines of text. In addition, I suspected
that I missed some reason why `contextMenus.update` and `remove`
promises are not rejected.