dbjorge

I think that even just on private machines, this would make some types of legal compliance needlessly difficult. If you ever need to delete that data, for example to comply with a corporate retention policy or in response to a request from an individual in a jurisdiction that requires you allow doing so, you would need not just to rewrite history but also to ensure that history is rewritten in every clone that any employee has ever made of that repository; there might not even be a record of which clones exist.

I used the Matias Ergo Pro for exactly 14 months. After the first month I bought a second for home. At 13 months (ie, one month out of warranty), the first one started having reliability issues with the quiet click switches failing. At 14 months the second keyboard started failing in exactly the same way, also one month out of warranty. Their support was unwilling to help outside the warranty period.

Recommend staying away from them.

This is a neat tool, but unfortunately, text art like this generates is extremely unfriendly to folks that use screen readers. If you do use this for comment documentation, consider making sure that there is also a written description above/below it with equivalent descriptive content.

Living in constant fear that a Google algorithm may someday decide to ban our extension without providing a reason, advance notice, or a meaningful appeals process. It feels like there's some new horror story describing this situation at least once a week here on HN.

My team is still using yarn v1 because we want both dependabot support (rules out yarn v2+ and pnpm) and support for overriding transitive dependency versions to force security fixes (eg, yarn resolutions). We would love to explore other options but right now yarn v1 seems to be the only game in town that meets those requirements.

Once npm implements their recently-accepted overrides RFC, we're eager to try switching to that.

I don't think the article is using unclear wording; I think it is clearly arguing the exact opposite of what you're describing. I think the clearest demonstration of this is the concluding section, where the author specifically talks about using "is desktop/laptop" as a preferred alternative to breakpoints that are based on window size.

The article explains the technical details of the render process escape. Contrary to all the current replies to this comment, it does not look to me that this is using a generalized Electron escape; rather, it is using specific main/render IPC calls which Teams has implemented unsafely as the escape mechanism. Perhaps folks are confusing this with an electron sandbox issue because Teams happens to have called the variable containing their IPC APIs "electronSafeIpc".

I work for Microsoft on a moderately complex chromium extension. We've investigated porting it to Firefox (we've had a small but nonzero minority of users ask about it, and several of our engineers have a personal interest in it), but it's really hard to estimate ahead of time how much effort it's going to be. Most of the issues are not so bad to fix individually, it's just an unknown-length onion peeling exercise. It's especially challenging when a library/framework you use is impacted by a difference and its maintainers aren't motivated to improve compatibility; some examples of this we've run into include "Firefox's RegExp implementation doesn't support named capture groups" (but the library author doesn't want to make the code less readable by not using them) and "Firefox's auto-size behavior for extension popup UI (what you see when you click am extensions toolbar icon) sometimes sends spurious window resize events when the DOM is modified" (the UI control library we use has behavior to dismiss context menus on window resize, which this breaks).

The most painful incompatibility I've read about was in the Bitwarden extension, which basically doesn't support most operations in Firefox private windows because Firefox intentionally doesn't support getBackgroundPage() from there, and Bitwarden architected their extension to use that for all IPC between their frontend and backend layers. You can avoid that incompatibility by using runtime.sendMessage for that purpose, but they didn't know that at the time they wrote it (there's a warning about it in the MDN docs for getBackgroundPage now, but that warning wasn't there at the time). We happened to have gotten lucky in our extension in that we use sendMessage for the same purpose, but we certainly didn't know about that incompatibility at the time we were making the architectural decision.

Beyond just making it work, our team would also want to be able to automate regression tests against Firefox if we were to officially support it. For a long time, selenium was the most realistic option for that, but we switched away from selenium to puppeteer a year ago due to reliability issues with the former. Now that Firefox support in puppeteer is very recently starting to stabilize, we're hopeful we'd be able to use that, but we haven't tried it yet and it's new enough that we wouldn't expect it to be fully compatible/stable yet.

The article notes near the top that extensions are supported, and also answers your other questions.

On Android I use an app called Materialistic, which has a dark mode