Disabled TableColumnDateText tests on WebKit due to date formatting differences

[jattasNI]

🧹 Tech Debt

Several TableColumnDateText tests have been disabled on WebKit due to errors like this:

Expected 'Dec 10, 2012 at 10:35:05 PM' to be 'Dec 10, 2012, 10:35:05 PM'.

We need to either fix and re-enable the tests or file an issue upstream (e.g. to webkit) and mark this blocked.

Search for this bug ID in source for a complete list of such tests.

[mollykreis]

@jattasNI, it's interesting that these tests are failing for you. When I run npm run test-webkit locally with all the #SkipWebkit tags removed, I don't see any test failures for the date-text column. How did you run the tests when you saw the failures? Did you run them locally? If so, I'm assuming that was on a mac?

[jattasNI]

@mollykreis My system setup is:
macOS 14.3
Safari Version 17.3 (19617.2.4.11.8)
Playwright webkit browser
I previously had my system locale set to "en-CA" and thought that might have been the cause of the difference, but changing it to "en-US" made no difference. The tests fail in both Safari and Playwright locally because of the "at" vs "," difference.

It appears to be a behavior difference in the Intl.DateTimeFormat in WebKit, but only on macOS?

[mollykreis]

That's interesting. They pass on my machine (Windows 10), and I just verified that they pass on the GitHub pipeline.

Any thoughts on the best way to resolve the issue? Should I close it since it passes on the pipeline?

[rajsite]

For other formatting differences we have been capturing it in pageObjects. II can't find the example anymore but that would be nice to do to enable devs across platform

[jattasNI]

Yeah, ideally we'll find a way to enable the tests so they pass on Windows dev machines, macOS dev machines, and Linux agents. I'd find it annoying if they were permanently disabled or failing on the OS I use for dev.

I don't recall the browser-specific page object example Milan mentioned. It'd be cool to abstract away like that, but I'm not sure how it'd work since our page objects usually have methods like getRenderedText(). Would we instead expose methods like containsRenderedText(segments: string[]) and call it like containsRenderedText(['Dec 10, 2012', '10:35:05 PM'])? That slightly weakens the assert we're making but maybe it's good enough.

Another alternative would be to create one test that's permanently disabled (via tags like SkipWebkit) on certain configurations and a corresponding test that's permanently enabled on the inverse configuration. But that might require new tags like SkipMacOS/SkipWindows and new commands for running them. I could see that getting complex.

[rajsite]

I don't recall the browser-specific page object example Milan mentioned.

This formatting normalizer used by duration and date columns was what I had in mind. It handles both a difference in chrome (not mentioned in the comments) and a difference across languages inside the page object:

nimble/packages/nimble-components/src/table-column/testing/table-column-formatted-text.pageobject.ts

Lines 10 to 14 in 626b6c7

	// When text is localized to different languages, the space character
	// can get changed to a different unicode variant. This regular expression
	// matches both known unicode variants so we can change them back to a
	// regular space to perform consistent checks for testing purposes.
	private readonly spaceUnicodeCharsRegEx = /\u202f|\u00a0/g;

[rajsite]

The important detail being having the page object hide browser-specific details, not having different page objects per browser or something.