Tom Schuster

Mhm, you are right. Clicking an item would relatively soon trigger the [`historyOnVisited` callback](https://github.com/nt1m/livemarks/blob/a5fb17f1f2c55270cafe50c70df39eb3b0627f04/background/background.js). This will trigger an update for all the livemarks in that containing folder. The idea here...

I think this is another issue with tracking protection or similar: > Request to access cookie or storage on “https://mail.google.com/mail/ca/u/0/feed/atom” was blocked because it came from a tracker and content...

Now that Firefox doesn't handle `feed:` anymore, maybe we can make a compelling case to allow `registerProtocolHandler` for that scheme/protocol. https://bugzilla.mozilla.org/show_bug.cgi?id=1571396

Maybe we should make the "Boomarks Toolbar" our default bookmarks folder.

I wonder if returning `null` instead of `false` would be a bit more consistent with APIs like Object.getPrototypeOf that return either an object or null. I guess `false` was chosen...

They are not enabled by default in 105, but behind a flag. https://searchfox.org/mozilla-beta/source/modules/libpref/init/StaticPrefList.yaml#7633-7638 https://bugzilla.mozilla.org/show_bug.cgi?id=1787070 will enable them.

There is a (stalled?) [stage 1 proposal](https://github.com/claudepache/es-legacy-function-reflection) for specifying actual caller and arguments accessors.

I can't reproduce this issue. Are you sure the add-on is enabled?

I think this should now be possible to implement in Firefox Nightly, because [bug 1322748](https://bugzilla.mozilla.org/show_bug.cgi?id=1322748) just landed.

I think we could remove the API docs for mozItemCount, mozClearDataAt, mozGetDataAt and mozSetDataAt, because those are definitely unusable now. mozCursor, mozUserCacelled and mozSourceNode stil seem to exist.