@owlmeans/test-ui 0.1.18-rc.11 → 0.1.18-rc.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/agent-meta/manifest.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 2,
|
|
3
3
|
"package": "@owlmeans/test-ui",
|
|
4
|
-
"version": "0.1.18-rc.
|
|
5
|
-
"generatedAt": "2026-
|
|
4
|
+
"version": "0.1.18-rc.12",
|
|
5
|
+
"generatedAt": "2026-09-01T12:04:42.699Z",
|
|
6
6
|
"canonicalRepo": "https://github.com/owlmeans/common",
|
|
7
7
|
"entries": [
|
|
8
8
|
{
|
|
@@ -196,3 +196,37 @@ See `[[shadcn-web]]` for the full `@` alias contract and `tests/context.ts` patt
|
|
|
196
196
|
- **Max 3-4 tests per component**: render, primary interaction, one edge case.
|
|
197
197
|
- **Always `close()` the page and `closeBrowser()` in `afterAll`.** A leaked context blocks the bun process from exiting.
|
|
198
198
|
- **Chromium only by default.** Add `firefox` or `webkit` per package only when the feature has documented cross-browser concerns — call `chromium.launch` / `firefox.launch` explicitly in that case.
|
|
199
|
+
|
|
200
|
+
## `mountComponent` waits for `domcontentloaded`, not `load`
|
|
201
|
+
|
|
202
|
+
Playwright's own default is `load`, and it is wrong for any page that is a real application:
|
|
203
|
+
`load` waits for EVERY subresource, so one analytics beacon, long-poll or third-party pixel that
|
|
204
|
+
never settles holds the navigation open until it times out — with the page fully rendered and
|
|
205
|
+
working the whole time. The failure reads as "the site is down", and the first instinct is to go
|
|
206
|
+
looking at the server.
|
|
207
|
+
|
|
208
|
+
`mountComponent` therefore navigates with `domcontentloaded` and lets the spec wait for the
|
|
209
|
+
selector it actually needs. That wait IS the assertion; the load event never was. Pass
|
|
210
|
+
`waitUntil` explicitly for the rare case that wants otherwise.
|
|
211
|
+
|
|
212
|
+
The rule is not `mountComponent`'s alone — **every** navigation helper here follows it, and
|
|
213
|
+
`loginViaSupervisorForm` / `loginViaDispatcher` are the ones that bit: they kept playwright's
|
|
214
|
+
default long after `mountComponent` was fixed, so adding a tag manager to an app broke its whole
|
|
215
|
+
login-driven suite while the browser showed a working login form.
|
|
216
|
+
|
|
217
|
+
## The consent dialog blocks the login form, and the failure blames the button
|
|
218
|
+
|
|
219
|
+
An OwlMeans app asks for cookie consent **before** it will start an authentication flow, and the
|
|
220
|
+
dialog is a modal with no dismissal — a decision is what the gate is waiting for. Until it is
|
|
221
|
+
answered the overlay intercepts pointer events, so a login form renders, resolves, reports itself
|
|
222
|
+
`visible, enabled and stable`, and still cannot be clicked. Playwright retries for the full timeout
|
|
223
|
+
and then reports `click: Timeout … waiting for getByTestId('supervisor-submit')`, naming the
|
|
224
|
+
button. Nothing is wrong with the button; read the `subtree intercepts pointer events` line, which
|
|
225
|
+
names `[data-consent-dialog]`.
|
|
226
|
+
|
|
227
|
+
`loginViaSupervisorForm` therefore calls `acceptConsent(page)` after navigating. `acceptConsent` is
|
|
228
|
+
exported for specs that drive their own login: it clicks `[data-consent-accept-all]`, waits for the
|
|
229
|
+
dialog to detach, and returns `false` at once when there is no dialog, so an app without the widget
|
|
230
|
+
is unaffected. It accepts **all** categories deliberately — a spec asserting a narrower decision
|
|
231
|
+
must make that decision itself rather than inherit a silent minimum. Pass `consent: 'ignore'` to
|
|
232
|
+
answer the dialog in the spec instead.
|