I'm developing a chrome extension that renders and sidebar iframe in Gmail.
A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as
Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...
To fix it, we had to rewrite the CSP header as explained in this blog post.
However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.
As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.
Notes and attempts:
Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.
We've tried to remove and re-add the extension but that didn't yield any permanent results.
Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.
[Update]
It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.
More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.
I can provide snippets and more info if needed.
Related
I have built an extension that keeps track of all the pages which are loaded in a browser session. Recently, I started seeing extra pages in my logs, pages that were not getting actually rendered on the browser.
I tried to find out more about it and learned that it is the "page preload" feature of the browser that these websites are using. Basically, if you specify a link tag with preload option, the associated page will be loaded silently in the background (https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content). For these pages, three of the four chrome.webNavigation events are getting fired - onBeforeNavigate, onCommitted and onDOMContentLoaded. I also looked into the transitionQualifier of the onCommitted event but does not give enough information to single out page preloads.
Any ideas around how do I detect that the page was not loaded in the conventional sense but was preloaded?
Also, if someone knows how can I disable the page preload feature in Chrome through commandline switches, I might just block all preloads and my extension would still work.
We are having an issue with the following div been injected into our site:
<div class="GoogleCreativeContainerClass" id="gcc_*****" data-creative-load-listener="">
It doesn't seem to break anything apart from ie9. It is getting injected in the middle of an SVG sprite sheet and breaking the SVGs.
I believe it's coming from GTM but we have 300 scripts loaded in via GTM!
Probably you resolve this already, however, and just in case, this is coming from any GTM tag which is displaying ads on your web site.
GTM is generating a list of data-dcm atributes that are used during the ad-render for each ad-placement you have configured.
The only way to avoid this is removing any specific ads that are displayed at your web site, when the browser is IE9 as you mentioned.
I am using the gtag.js linker plugin, and its autoLink feature. When I turn GA debugging on, I see in the console:
Link decorated: https://mysedanweb.limosys.com/JlimoWeb/?y=&_insput=3147729489-1348501718&_ga=2.163929663.1298871253.1551969782-111678887.1551969782
Navigated to https://mysedanweb.limosys.com/JlimoWeb/?y
So in other words, the link decoration is working, and appears to happen prior to the browser navigating to the next page, but it navigates to the url without the additional parameters. So, cross-domain tracking doesn't work.
Has anyone seen this problem? Any solutions?
You have a malformed URL.
https://mysedanweb.limosys.com/JlimoWeb/?y=**SOMETHING**&_insput=3147729489-1348501718&_ga=2.163929663.1298871253.1551969782-111678887.1551969782
You need to specify a value for y .
I originally set this page up a few weeks ago, and it was working fine until the site went live and it was changed to ssl.
We've been in contact with the devs who made the page in the iframe, and got them to switch to ssl and made sure they have included the iframeResizer.contentWindow.min.js file on their end.
I've also been running a test from one of my other sites to make sure everything was been set up properly on my end, and that worked no problems.
Link to page with iframe: https://www.bedsrus.co.nz/sleep-selector
My test page used to check my setup: https://www.bedsrus.co.nz/test
Logging has been left on, if you'd like to have a look.
I've tried changing the heightCalculationMethod to to some other options including lowestElement, bodyScroll, and max.
There are a few warnings coming from the content page but I don't think they would be causing the problem.
Any help would be appreciated.
Managed to figure this one out.
The containing doc had the html and body elements set with height: 100%.
This was confusing the iframe resizer as some of the elements in the body were floating.
Setting the containing documents html and body elements to height: auto fixed this issue.
Just had a quick look and on https://www.bedsrus.co.nz/sleep-selector your using v1.4.4, where as the iframe is running the latest version of the script (v2.8.6)
Whilst this does work, you need the latest version on the both pages to use all the features of the current version.
The script isn't logging to the console on your test page.
I'm currently building a website for our business, where the website is expected to work perfectly, even back to the earlier IEs down to 7.
URL - https://secure.marietta.at
The page does not load any insecure content in Chrome, but I can see in IE that there is a GET param sent to http://marietta.at, which in turn redirects to http://en.marietta.at
I have no idea where I've specified this. I tried deleting scripts, checking the css, debugging with IE's own debugging tool and in HttpWatch Studio. I can't find the offending piece of code.
Are there any particular gotchas in IE that might trigger this warning?
Your HTML source contains the line
<script type="text/javascript" src="js/jquery.min.js"></script>
which makes the browser try to fetch the URL https://secure.marietta.at/js/jquery.min.js. However, this URL doesn't actually return any JavaScript code like you'd expect it to, but instead redirects to http://marietta.at/.
The fact that you later load another, working copy of jQuery from another URL hides this problem.
I would suggest either of the following solutions:
Remove the broken jQuery URL from the page.
Put an actual copy of jQuery at that URL so that it works (and remove the other, now redundant copy from the page).
I'd also suggest configuring your webserver so that it doesn't redirect from HTTPS to HTTP URLs, as that may violate the user's security expectations in general.
Load your page in IE and view the source code. There are quite a few hard coded references to http://en.marietta.at. Seems like some of your jQuery calls might be loading that "insecure" content
Ok, I've figured it out - never load JQuery twice (esp. from with an invalid URI). I've mistakenly left it in the <head> and just above the <body> tag which resulted in the SSL error. Deleted one, which got rid of the error.