UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
1. Serve a X-XSS-Protection header with the reporting URL with a different origin
2. Observe the error "insecure reporting URL for secure page at character position 10. The default protections will be applied."

What is the expected behavior?
The error should have been "reporting URL is not same scheme, host, and port as page"

What went wrong?
https://chromium-review.googlesource.com/c/chromium/src/+/768367/3/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp introduced a check for whether the report URL has the same origin as the request. The added code will blank out xss_protection_report_url. However, since the IsMixedContent check immediately afterwards is using xss_protection_report_url, it now reports it as mixed content, even if both origins are HTTPS.

I believe the fix is to (optionally switch the order of these two checks and) put the second check behind an else, so that they will not trigger each other.

Did this work before? N/A 

Chrome version: 64  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: