mmazzarolo

This looks great, thanks for sharing!

Lol. It did, back in the day, with people saying "this is not accurate, since it's only a EU thing".

Thanks, that was my intention (back when I posted it). I added "from EU" just to make it clear—since people would have otherwise said "that's not how it works in the US :p"

I mean... I just recorded a browsing experience? It's the entire experience in general that sucks imho, regardless of cookie consent popups or not.

JavaScript, Web Development, React (Native), macOS, productivity tools: https://mmazzarolo.com

Spotify

Author here. That was a mistake on my part, it shouldn't have slipped in :) I removed that section, thanks for reporting!

Author here. This article is my take on automating visual regression tests of a “modern” web application using Playwright and GitHub actions. The goal is to build a "minimal" testing setup that checks for UI regressions on each pull request and allows selectively updating the baseline images when needed.

FYI I’m experiencing the same identical issue with the latest version of iPadOS.

Off the top of my head:

- Overriding the fetch/XHR API for error monitoring (there's no other way to listen for them unless you use Service Workers)

- Polyfilling features on top of existing APIs

But you might not see them as "justified".

Thanks! Crafting a tutorial wasn’t as easy as I initially though/hoped :)

I’m not a fan of many UX/UI choices here, but complaining about the “lack of dark mode” in a beta product feels a bit too much in my opinion.

Looks cool! I'm also wondering how much this 4-letter domain is worth.

https://bugs.webkit.org/show_bug.cgi?id=241756

That's nice to hear. It really was a bug, then.

I did not. I already wasted enough time and energy in the past reporting a security vulnerability in Safari's CSP to know that reporting it is not worth it.

The “play” method is enough to trigger the full screen — which, by the way, isn’t really intuitive imho.

I would still consider a missing safety check (like in this case, to check if there’s already a full screen video open) as a bug.

At this point I’m not even sure if the post is talking about the same thing you’re mentioning. It’s not about “global state” in a sense of state available across the app, it’s specifically about not using the JS engine’s global object (https://developer.mozilla.org/en-US/docs/Glossary/Global_obj...) to avoid common pitfalls.

If you don't know the global names, I would probably do something like this:

1. Grab the name of all globals your JS code is creating (using https://mmazzarolo.com/blog/2022-02-14-find-what-javascript-...).

2. Inspect all of them with the technique used in the article and update the inspection logic so that it checks does a deep check of the value "HelloWorld123" as well (the value can be accessed here: https://gist.github.com/mmazzarolo/2b325f3af2bc83f56d3c921ff...)

Hey! Was this a response to another comment? In the post I'm explaining why it's happening (and it's just purposely bad code to show a global instantiation example)

To me, there are two many reasons to avoid the global scope:

1. Like prototype extensions of JS types like "String", you're basically using a namespace that in the future might be used by a built-in API of the JavaScript engine — which would break your code.

2. You don't know for sure where your code will run in the future. A couple of years ago I worked on a migration where "standard" SPA were migrated to a micro-frontend app (where multiple SPA could be loaded on after another at the root level and each SPA would have to clean-up its own globals and listeners).

BTW I'm not against it — I DO put some stuff in the global object. If you put your entire state in a namespace like __MY_CUSTOM_SPACE__ the risk of encountering those two issues is basically 0. But I still thing there aren't many valid reasons to do so, especially with nowadays' toolings.

Thank you. That's a nice idea :)

Author here! In this post I'll explain a method to debug what JavaScript code is adding global variables to the window object. Hope it can help! Open to questions and feedback.

Author here! I recently finished writing "Running React Native everywhere": an opinionated tutorial on how to run React Native on multiple platforms using Yarn workspaces.

You can see the final result in the react-native-universal-monorepo GitHub repository (https://github.com/mmazzarolo/react-native-universal-monorep...).

It currently supports:

- Android

- iOS

- Windows

- macOS

- tvOS (tutorial here: https://finnternet.com/dev/blog/react-native-tv-monorepo)

- Android TV (tutorial here: https://finnternet.com/dev/blog/react-native-tv-monorepo)

- The web (using Create React App)

- The web (using Next.js, tutorial here: https://finnternet.com/dev/blog/nextjs-monorepo)

- Electron

- A browser extension

Interesting, what's your MBP version?

Interesting. I'm wondering why wouldn't it be tied to the display FPS instead of the polling rate though.

What 60fps hard limit? You can already set it to 120fps if your monitor supports it (and it has been possible for a few years).

I've also been hearing coil whine sound coming from MacBook's Caldigit dock when using a wired gaming mouse (only in totally silent rooms). I haven’t mentioned it in the article, but just like you said, lowering the polling rate fixes it too.

It almost makes me feel that I am breaking the law when scraping a site, yet web scraping is on of the most basic programming things.

Yeah, same for me.

Regarding the denylisting, I guess it depends on what is being scraped and how often the scraping happens? I'm maintaining a remote jobs aggregator website and I've never been blocked before (but I'm not scraping more than ~5 times per day the same web page). And with a caching strategy, I think that even a scrape-as-a-service API like the one I'm building in the article should be "kinda" safe (besides edge cases that brute force the cache constantly, like by adding random query-params)?