Also, as someone on the periphery of Selenium (mostly via WebDriver), some of the challenge is that Selenium has a huge amount of test code already written for it — and making radical API changes would break every test already written for it, and at that point you’re effectively a new library.

It’s gonna be very interesting to watch exactly how the adoption of WebDriver BiDi goes with Selenium, especially once WebDriver Classic starts to go away, and how API stability is balanced with exposing more and more async capabilities.

> Performance isn't all that matters, especially once you have an established codebase and ecosystem.

And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)

It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.

Is there any plan about how to deal with indirect prompt injection attacks that could trivially be lurking in malicious web pages, given the agent can navigate to an arbitrary URL?

short-term mediation is always always always run it in a virtual machine with as minimal credentials as possible.

Is there anything at a protocol level that prevents using a modern font rendering stack for it?

Not just WM/DE, but also the toolkit too.

I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.

That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).

This is exactly the sort of breaking change that I really struggle to see the value of — maintaining the deprecated method seems incredibly unlikely to be a notable maintenance burden when it is literally just:

    @deprecated("Use response.headers.get(name) instead")
    def getheader(self, name):
        return self.headers.get(name)

Like sure — deprecate it, which might have _some_ downstream cost, rather than having two non-deprecated ways to do the same thing, just to make it clear which one people should be using; but removing it has a much more significant cost on every downstream user, and the cost of maintenance of the old API seems like it should be almost nothing.

(I also don't hate the thought of having a `DeprecationWarning` subclass like `IndefiniteDeprecationWarning` to make it clear that there's no plan to remove the deprecated function, which can thus be ignored/be non-fatal in CI etc.)

There is value for the person maintaining this library cause they want it that way. If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months. I'll roll with it.

I definitely agree with the sentiment that people working for free can do whatever the heck they want.

But if you're trying to help your users and grow your project, I think GP's advice is sound.

You are, of course, correct.

But the fact that they made a new release with it undeprecated shows they _do_ care about their users (direct and indirect), and at least from my point of view (both from the Python ecosystem and the browser ecosystem) this was a pretty foreseeable outcome.

> If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months.

That would make it no longer a useful library

Note the spec does recommend providing a user option: https://drafts.csswg.org/css-color-hdr-1/#a11y

The second link isn't applicable to Apple's WebKit ports — it's entirely built via Xcode.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines USE_JPEGXL only for macOS < 14 (which aren't actually supported any more!).

All the in-tree JPEG XL support, e.g., https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... is behind a "USE(JPEGXL)" ifdef — so none of that is compiled in.

Instead, it's using what Apple ships at a system level, in Image I/O.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines HAVE_JPEGXL for recent versions of Apple's OSes. https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884... is the commit which added this — there's really not much there, because it's just setting the define and adding it to the allowlist of image types.

And yeah, currently I believe this is libjxl — or a fork thereof — hence the inclusion of libjxl in the Acknowledgements.rtf file on macOS.

Arguably this is a problem in when the patch is unapplied.

Presumably in the coverage case it’s being called by a trace function, which inevitably runs during test execution — and while we want the trace function to be called during the test function, we really want it without any patches the test function is using. But this arguably requires both an ability for the trace function to opt-out of patches and for the patcher to provide a way to temporarily disable all of them.