Mixed content warnings for unidentifiable insecure font, "https:"
Reported by
simon.sc...@gmail.com,
Nov 5
|
||||
Issue descriptionChrome Version : Current version = 70.0.3538.77. First version this issue occurs in = 66.0.3359.0, Last version this issue wasn't in = 65.0.3325.0 URL : https://www.bbc.co.uk/sport/football/transfers (+ most of the pages on BBC Sport). https://www.horizonhomes-samui.com/ Behavior in Safari 4.x/5.x: No mixed content warnings Behavior in Firefox 3.x/4.x: No mixed content warnings What steps will reproduce the problem? (1) Go to above URLs (2) Observe the blocked content shield (3) Check console. See several warnings stating: `Mixed Content: The page at 'https://www.bbc.co.uk/sport/football/transfers' was loaded over HTTPS, but requested an insecure font 'https:'. This request has been blocked; the content must be served over HTTPS.` Clicking down the warning sources, the code "responsible" is non-sensical. This seems to be obfuscated by some bad webpack source mapping. I originally saw this shortly after we pushed the BBC Sport website to HTTPS-only. After lots of wrangling, we've pared it down to the version this issue it was introduced in, but with my limited knowledge of internal browser behaviour, I can't see anything obvious in any changelogs that might have caused it. I recently re-googled it, and found somebody has recently had the same issue here: https://stackoverflow.com/questions/53045992/how-do-i-resolve-the-mixed-content-error-the-page-requested-an-insecure-font-h. And having tested it in those Chromium builds get the exact same behaviour (no issue in 65, issue present in 66). There seems to be little obvious in common between our two HTML source codes. I've attached some screenshots of this occurring in vanilla Chromium builds.
,
Nov 6
,
Nov 6
That’s the weird part of this issue, and why it’s been a lower priority on our backlog. The only user facing symptoms are the logs (which I should have screenshotted really for clarity), and the shield to the right of the url bar. It never invalidates the certificate, like you see in “real” mixed content issues.
,
Nov 6
>> The only user facing symptoms are the logs (which I should have screenshotted really for clarity), and the shield to the right of the url bar. Similar behavior on my end when using Chrome. The padlock to the left of the URL bar remains intact.
,
Nov 6
Able to reproduce the issue on Windows 10, mac 10.13.6 and Ubuntu 17.10 using chrome reported version #70.0.3538.77 and latest canary #72.0.3602.0. Bisect Information: ===================== Good build: 66.0.3328.0 Bad Build : 66.0.3329.0 Note: Unable to provide per-revision bisect results as on running the per-revision script getting error as RuntimeError: We don't have enough builds to bisect. revlist: []. Hence, providing chromium bisect results. Change Log URL: https://chromium.googlesource.com/chromium/src/+log/060e1aacae0500e12dbb746ef4242dc3ec49eadb..b301a6526484d3419a096a874c00b38e69e63988 From the above change log suspecting below change Change-Id: Ia829664d33863558e3b816d256f6d0e9b2d10723 Reviewed-on: https://chromium-review.googlesource.com/879817 caseq@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Dec 28
To krajshree@ in #5: how did you arrive to the conclusion that this behavior has changed as a result of a chance you're pointing to, which is a change in the protocol method documentation?
To original reporter: while the diagnostic message could be better, this is really caused by the page trying to load a font that has "https://" as its URL -- please take a loot at the Network panel. A quick search over the files of the page shows this:
document.write('<style id="font-face-test">@font-face {font-family:"font";src:url("https://")}</style>'),
in https://static.bbc.co.uk/onesport/2.11.670/js/compiled/inline-rjs.js
Over to mkwst@ as one of loader owners to consider different wording in case the URL is just invalid.
|
||||
►
Sign in to add a comment |
||||
Comment 1 by cagr...@gmail.com
, Nov 6