-
Notifications
You must be signed in to change notification settings - Fork 383
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
Auto-reject excessive CSS validation errors #3346
Auto-reject excessive CSS validation errors #3346
Conversation
The `AMP_Validation_Manager::is_sanitization_auto_accepted()` now accepts an `$error` as argument and auto-rejects the specific case of an excessive CSS validation error. In addition, the Tag & Attribute sanitizer specifically ignores the `<style amp-custom>` tag when it comes to the `max_bytes` rule in the spec.
Co-Authored-By: Weston Ruter <westonruter@google.com>
Lots of broken tests for this change, will have to go through them and see what exact Pandora's box I actually opened here... ;) |
It may be just a matter of replacing |
Alternatively, if the return value of |
Is that something we should add anyway? |
I think so. I think it makes sense to be able to give the ability to filter whether a given validation error is auto-accepted. This would be needed when removing the auto-accept checkbox, ultimately. |
There's only one failing test now: https://travis-ci.org/ampproject/amp-wp/jobs/589550895#L1035-L1044 The amp-wp/tests/php/test-tag-and-attribute-sanitizer.php Lines 1818 to 1836 in 5888398
The current logic is ignoring I could of course change the test now, but I wonder if there's no way to make the edge case I'm overriding more specific so that the test wouldn't break here. I can't think of a way though. @westonruter Thoughts? |
The only way I can think of here without modifying the tests is to check from within the Tag & Attribute sanitizer whether we have NEW_REJECTED validation errors in the current document. However:
So for now I'm going ahead and changing that test instead, but let's discuss further as needed. |
As I don't actually need it here, I'll open a separate issue for that. Link: #3350 |
I added tests for:
I think this should cover the current behavior. The style sanitizer did not require any changes. However, right now, the CSS manifest comment does not contain any added information. I'm not sure if we should add something there or not. |
Looks Good Hi @schlessera, On testing this with Query Monitor to ensure the CSS is above 50 KB, the ...and the Before this PR, the Query Monitor CSS was removed, as it put the CSS over the 50 KB limit. |
* @return bool Whether sanitization is forcibly accepted. | ||
*/ | ||
public static function is_sanitization_auto_accepted() { | ||
return amp_is_canonical() || AMP_Options_Manager::get_option( 'auto_accept_sanitization' ); | ||
public static function is_sanitization_auto_accepted( $error = null ) { |
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.
Good idea to accept an optional $error
parameter.
The
AMP_Validation_Manager::is_sanitization_auto_accepted()
now accepts an$error
as argument and auto-rejects the specific case of an excessive CSS validation error.In addition, the Tag & Attribute sanitizer specifically ignores the
<style amp-custom>
tag when it comes to themax_bytes
rule in the spec (introduced in #3084).Finally, to ensure that the resulting
<style amp-custom>
is not stripped itself for excessive size, the tag & attribute sanitizer treats this tag as a special case for enforcing the'max_bytes'
spec rule.Fixes #2326