-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try using axe disableFrame function to resolve Axe end to end test error #26535
Conversation
Size Change: +1.48 kB (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
It would explain why it fails also for the demo test:
It triggers the preview as well. The way to go would be rather to find a way to ensure that the page that is about to be validated contains the block editor. We surely don't want to validate about:blank page.
In theory, we check whether there is a block editor on the page here and bail out when the condition is not met: gutenberg/packages/e2e-tests/config/setup-test-framework.js Lines 183 to 185 in 0ebfa98
It looks like tests should wait until the preview is loaded before it finished as it probably happens that at the time axe starts processing navigation between pages takes effect. |
@gziolo I didn't realise that. I thought it just loaded the demo and then checked the dirty state. |
Ah, wait. I misinterpreted this code. Anyway, something goes wrong there as well. So maybe there is something strange happening that creates iframes that are empty? It might be also an issue with axe itself, since we upgraded to v4. |
The stack trace does seem to indicate it's caused by axe. The embed mocking in that test creates an empty iframe, so that could be related? The other thought I had is that it doesn't like the multiple |
Well, all checks have passed twice in a row now, which seems like more success than we've had lately? I might just want to double-check that I haven't disabled axe tests entirely 😅 |
Let's make sure that those axe tests still verify enabled rules. How about this new option is marked as experimental for the start so we could validate if it solves the issue? This way we won't need to document it inside |
I commented out some skipped axe rules to see if axe still works. Feel free to remove 01eff11 once we know :) |
There are valid failures reported which means that everything works perfectly fine with the changes proposed. I'm happy to approve this PR when |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This proposed solution with the disabledFrames
looks good to me! Also supporting the __experimental
recommendation.
'button-name', | ||
'color-contrast', | ||
'dlitem', | ||
// 'button-name', | ||
// 'color-contrast', | ||
// 'dlitem', | ||
'duplicate-id', | ||
'label', | ||
'landmark-one-main', | ||
// 'label', | ||
// 'landmark-one-main', | ||
'link-name', | ||
'listitem', | ||
'region', | ||
// 'listitem', | ||
// 'region', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might have missed it in the discussion. Was there a reason we are commenting out a handful of the disabled rules?
nevermind i see it in comment - #26535 (comment) - is the idea to re-enable (or re-disable 🤣 ) these before merging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also worth noting #26527 seems to be passing now (3x in a row at least) that I updated the selector for block previews from the container to the content. So that might still make sense as an alternative (or addition) to this?
Its a bit less 'experimental' in nature than what we are doing here with the undocumented disableFrame
, but I agree the approach here also makes sense and that disabling everything under [aria-hidden="true"]
seems like it should be done in general for axe tests. 🤔
Agree it should be experimental for now. I've made those changes. |
Ah, well on the last run this also just failed with the same iframe error:
So I guess this won't solve the issue either. |
Another alternative, we can ignore the logged message - #26590 |
Description
Currently axe core tests are failing intermittently on this test:
There's an error injecting axe core scripts into iframes created by the block preview.
#26527 tried to use the exclude option to make axe ignore block previews, but Axe still tries to inject the script.
Axe has a
disableFrame
function that looks like it prevents axe from inject scripts into specified iframes. Its undocumented (dequelabs/axe-core-npm#39), so not sure how we'd feel about using it.This PR tests it out.