Hey, everyone. First, big thanks to everyone who contributed to this discussion.
Second, I am generally supportive of building a Geb layer that can use Playwright as a driver. Geb was deliberately built to use Selenium as an implementation detail, not at the API layer. Its content DSL and other features should, in principle, be implementable in Playwright's Java bindings. That said, my own experience with Playwright is a bit more mixed, and I have much lower confidence that it can deliver on less flaky browser testing promise. If our deeper objective here is to address flakiness, I'd like to consider more deeply Selenium's support for WebDriver BiDi <https://www.selenium.dev/documentation/webdriver/bidi/>. They've committed to moving much of Selenium's implementation to that without breaking backwards compatibility. So while James Daugherty's note about Playwright's strength was true at its first release, I think that's less true today. Selenium should have access to the same event-driven strengths as Playwright via the open BiDi standard. While I can see that the AI-generated design has some words on this <https://github.com/jdaugherty/groovy-geb/blob/master/design/geb-playwright-backend-plan.md#23-why-not-webdriver-bidi-inside-selenium-instead>, it strikes me as... well, I don't quite trust the AI's analysis, frankly. There may be some grains of truth in the particulars, but I don't buy that it would translate directly into a difference in flaky tests. Please feel free to prove me wrong if you've already got the builds to show otherwise! A couple of thoughts: 1. I'd be more comfortable merging James Fredley's PR if we called the module geb-playwright instead of geb-direct. That way it would be clear exactly what the module's implementation was based on, and that its goal was to be an implementation on top of a specific vendor, similar to geb-spock and geb-junit. "geb-direct" sounds more fundamental than the module really is. 2. I'd prefer we mark it as an experimental feature. For personal reasons, I've been fairly time-constrained lately and I don't think I'll have time to give that PR a proper review and test. 3. I'd like to throw some clankers at the PR for an antagonistic review centered around the idea of, "Is this the simplest thing that could possibly work? How could the same goal be accomplished with less code?" and similar things. While the code at first glance doesn't have too many of the hallmark traces of AI slop (i.e. overly verbose JavaDoc, etc.), I'm always suspicious that the AI code generators are overcomplicating things. If someone wants to beat me to this, more power to you. Thanks very much for the enthusiastic contribution and your patience while I've been getting caught up. Best, Jonny On Wed, Jul 22, 2026 at 1:21 PM James Fredley <[email protected]> wrote: > Since selenium continues to cause Flaky tests on the > https://github.com/apache/grails-core builds, I prioritized this. > > https://github.com/apache/groovy-geb/pull/330 - Add optional geb-direct > Playwright backend, the PR also links to a grails-core repo branch which > can be used to test this locally. > > I noticed some dependencies are not the most recent, on master, and I > would be glad to contribute PRs to update those also. > > James Fredley > VP, Apache Grails > > On 2026/07/03 23:00:51 James Fredley wrote: > > Hey folks, > > > > I’ve been thinking about ways to bring some of Playwright’s strengths > > (BrowserContext isolation, built-in auto-waiting for actionable > > elements, strong locator strategies, tracing with > > screenshots/DOM/network, video recording, and network interception) into > > Geb without forcing everyone to change. > > > > Since Geb is currently tightly coupled to the Selenium WebDriver model, > > a clean path could be an optional geb-direct module under > > org.apache.groovy.geb. It would depend on the official Playwright Java > > bindings, add a configuration-driven backend (something like driver = > > "playwright" or a playwright { browser = "chromium" } block in > > GebConfig), and map Geb’s Navigator/content DSL, Browser, $(), waitFor, > > Page at checkers, and modules onto Playwright Locators and Contexts. > > This would let users opt in for the reliability and debugging wins while > > keeping all existing WebDriver/Selenium usage completely untouched as > > the default, and advanced features like tracing could hook into Geb’s > > existing Reporter system. > > > > I’d be interested in writing this module if there’s interest from the > > community. > > > > We have a large number of Geb tests in Grails-core and this would help > > them run smoothly in CI. > > > > James Fredley > > VP, Apache Grails > > > > On 2025/12/31 22:17:56 Jonny wrote: > > > I've been doing some thinking about Geb and what things I'd like to > get > > > done in the next year. > > > > > > This isn't so much announcing a formal roadmap as asking folks for a > > > wishlist for Geb. Here are some of the bigger bits that are on my > radar. > > > Does anyone else have things on theirs? > > > > > > *Bugfixes* > > > > > > *Better thread safety in GebTestManager* > > > > > > https://github.com/apache/groovy-geb/issues/201 and other issues > make me > > > think that GebTestManager makes some assumptions, particularly around > how > > > JUnit lifecycle methods handle tests, that just don't hold in all > > cases. My > > > hunch is that there are a lot of bugs embedded in this for parallel > > > execution. > > > > > > Some part of me thinks that the deep answer here is, at least in > part, to > > > use newer Java concurrency constructs, such as structured concurrency > > > <https://openjdk.org/jeps/453>, but that raises some backward > > compatibility > > > concerns. > > > > > > *Projects* > > > > > > *Testcontainers integration* > > > Carl Marcum's work back in October to provide some easy-to-use > > integration > > > between Geb and Testcontainers seems like a great thing to bring into > the > > > Geb project as a first class module. I'd outlined some thoughts on > that > > > <https://lists.apache.org/thread/k2z0nzdgxrzx2kx429pk6sddtd0r4g5n> in > > > another thread, but how do others feel? > > > > > > *Release automation* > > > I let this lapse a bit, but that may be a bit of a saving grace. > Apache's > > > Trusted Release Platform > > <http://github.com/apache/tooling-trusted-releases> > > > seems to be coming along, based on the talk in their Slack channel > > > <https://the-asf.slack.com/archives/C049WADAAQG>. > > > > > > *Bring example projects home* > > > We still have a bunch of example projects out in the old Github org. I > > > think those are probably best brought in as included builds in the > > main Geb > > > repo. This is basically what JMH does with their samples project > > > <https://github.com/openjdk/jmh/tree/master/jmh-samples>, and I > think it > > > would be a bit easier to maintain than scattered repositories. > > > > > > *Geb 9* > > > I'd also like to think ahead to breaking/backwards-incompatible > changes > > > that we'd like to make. > > > > > > 1. Require Java 25 to build, compile to Java 11 as target. Groovy 5 > > > requires Java 17 to build, Java 11 as target, so I figured we > > should be > > > conservative in what we allow, but aggressive in the tooling we > use. > > > 2. Groovy 5 (and supporting version of Spock, 2.4-groovy-5.0) > > > 3. Move from javax -> jakarta > > > > > > What about BiDi? > > > BiDirectional functionality in WebDriver > > > <https://www.w3.org/TR/webdriver-bidi/> is something we need to > think > > about > > > how to best expose in Geb. I haven't thought deeply about this, and it > > > frankly seems like the biggest blind spot that needs some light > shined on > > > it. > > > > > > What about AI? > > > AI-based testing obviously has huge implications for browser testing. > > > https://www.browserstack.com/guide/selenium-with-ai is a good read > > for some > > > near-to-hand reaches that Geb could follow or build on. What other > things > > > should we be considering in this vein? > > > > > > Thanks for any thoughts. Happy New Year! > > > > > > Best, > > > > > > Jonny > > > > > >
