FKAMP-5 Remove need to go to ampproject CDN before being redirected onto the original publisher
This removes one hop from the redirect chain, and subsequent ones are much faster as you _tend_ to speak to the same domain name for a publishers copy of the AMP as you would for the real page, so DNS is already done and there's a connection open already.
This change means that the Anti-AMP functionality still works on Google News with cdn.ampproject.org blocked in my adblocker
FKAMP-5 Update the Googlesearch hook to also work (sort of) with Google News
Introduces logic into {{AMPCheck}} to look for iframe's referencing the AMP project CDN. If found, it updates the page to point to that URL so that the normal anti-AMP scripts can fire.
The downside of this is it means there are a couple of page loads before you eventually land on the full-fat page, so there's definitely some room for improvement
FKAMP-3 Add script to redirect certain sites/domains to non-AMP enforcing alternatives
This is primarily for things like Google News where it's non-trivial to un-AMP them.
This current version redirects Google News to Bing News (which isn't something I ever thought I'd find myself willingly doing)
The intention is that this will only ever be used for domains that use AMP but don't declare it, or don't use {{canonical}} properly. Google are currently the only ones I've seen doing that so far
Previously, if the user clicked the "more" button to load additional search results, the new results would still be AMP'd. To fix this, we need to recheck all links after the additional results have been added to the page.
Clicking "more" results in many fires of the `DOMNodeInserted` event. This commit re-runs the AMP check after such an event, with a 500ms debounce.
Revert "MISC-29 Add slightly snarky and very temporary iframe detection to try and work around AMP detection issues on Safari when hitting Google's cache (see #2)"
This reverts commit 51400177ebdc778364be15fc06f2cc3b6c3629e3.
Further testing has identified the cause of the issues in Safari/Google Search, and this detection won't help with that.
Might be useful in the long run, but as it was thrown together quite quickly I don't feel it's been adequately tested so should be removed for now
MISC-29 Hacky hack fix to work around Google's behaviour
On an AMP compatible device, when the user clicks a link in Google's search results, they'll append {{&cf=1}} to the URL (presumably because they expect it to go via their ping page instead of direct).
This makes sure that ends up in the querystring rather than the url path.
Longer term, might be better to rewrite the ping url rather than just overriding href though
This basically just dumps the script created in that issue into a greasemonkey script - may very well not work (just easier to transfer to the Mac by putting into the repo).
In *theory* it should prevent Google using their own Amp caches (without a page reload) or even sending the user to an Amp page in the first place. Liable to be a bit fragile though...
MISC-29 Add slightly snarky and very temporary iframe detection to try and work around AMP detection issues on Safari when hitting Google's cache (see #2)
This involves doing a scan of the DOM, so might be quite expensive at times. The aim is to try and replace this once I've laid hands on a Mac to be able to repro the issue and troubleshoot it.
This allows TamperMonkey to run the script even on pages with a strict Content-Security-Policy (as TM supports adding itself into any CSP headers which are present).
It also results in faster trigger times, and means my CDN's logs now won't contain referrer strings showing peoples browsing history (which is a win for both them and me)
Ensure function returns after pushing redirect (MISC-25)
Otherwise, if the browser is slow to follow the redirect we'll still write subsequent console.log calls to console. Might make troubleshooting tricky at some point in the future.
I had originally planned to load the anti-amp Javascript direct from Github (using raw.) but unfortunately the browser refuses to run it because the content-type is returned as text/plain rather than application/javascript
Instead, we serve it via my CDN.
When adding the script anchor, we include a SubResourceIntegrity (SRI) hash to minimise the chances of a MITM (or compromise of my system) buggering anyone.