https://support.google.com/faqs/answer/6346016,I removed the code that related to TrustManager,but still google play rejected me. why this happen, how to solve?
Related
Previously working code that downloads a csv file from our site, now fails. Chrome, Safari and Edge don't display anything helpful except "Blob Blocked", but Firefox shows a stack trace;
Uncaught TypeError: Location.href setter: Access to 'blob:http://oursite.test/7e283bab-e48c-a942-928c-fae0907fdc82' from script denied.
Then a stack dump from googletagmanager
This appears to be a fault in the tagmanager code introduced in the last couple of weeks.
The fault appears in all browsers and is resolved immediately by commenting out the tag manager. The problem reported by a customer on the production system, and then found on both staging and locally. The customer advised they had used the export function successfully 2 weeks ago.
The question really is, do Google maintain a public facing issues log for things like the tag manager?
It's not about GTM as a library really, it's about poor user implementation. It's not up to Google to check for user-introduced conflicts with the rest of the site's functionality.
What you could do is go to GTM, and see what has been released in the past two weeks. Inspect things and look for anything that could interfere with the site's functionality. At the same time - do the opposite, see all the front-end changes introduced during this time frame by the web-dev team.
Things to watch for is mostly unclosured JS deployed in custom HTML tags. junior GTM implementation specialists like to use the global space, taking the global variables, often after the page is loaded, thus overwriting front-end's variables.
Sometimes, people would deploy minified unclosured code to the DOM, thus chaotically taking short var names. To the same end.
This is likely the easiest and most common way for GTM to break front-end. There definitely still are many ways to do so besides this though.
If this doesn't help, there's another easy way to debug it: make a new workspace from Default (or whatever is live), go into the preview mode and confirm that the issue still happens. Now start disabling newest created fired tags one by one and pinpoint which one causes the issue.
Let us know what it was.
Solution was to replace the previous tag manager code with the latest recommended snippet
I have code that used to work great which was taken directly from google developers tools. It is the autocomplete addressform. It still works but it is not saving the city parameter? Everything else is working and even if I check it on the google developers site it does not work? Have they changed something or is there an error they need to know about?
Googlemaps have changed the parameters, locality is now postal_town. I imagine a lot of people may be affected by this. Strange there is no documentation for this change and even their own site has not implemented it??!!!
I can confirm, google recently changed this field for UK. I have an web app that depended of this and I had to fix it.
I have created a little flight simulator based on milktruck demo. The problem is that the plugin crashes every couple of refreshes. I have no idea why that is. It happens on all browsers
You can see the game here
http://www.stepupforisrael.com/plane-game/0205/Mingame.htm
Any clue will be welcome....
I see, the issue is that after a few refreshes you get the error ERR_BRIDGE_OTHER_SIDE_PROBLEM and the detail is bad status
I believe this is a bug with how you are loading the plug-in itself - I can reproduce it using a very basic set up. Also, It looks as if there is already a bug report for it here.
http://code.google.com/p/earth-api-samples/issues/detail?id=736
Form reading around, and testing, it appears that loading the plug-in using the Google Loader resolves the issue. To do this.
Firstly, remove the onload 'init' call from the body element.
So that
<body onload='init();' onunload="//GUnload()">
becomes
<body onunload="GUnload()">
Then use the Google loader callback to handle the initialization. To do that place this line at the end of your script block, right before the closing element.
google.setOnLoadCallback(init);
My thinking is that the onload event occurs immediately after a page is loaded. However, sometimes the plugin has not finished authentication when this event occurs, hence the intermittent error. You can read more about this here: https://groups.google.com/forum/?fromgroups#!topic/google-earth-browser-plugin/vvXKanCJbJU
We had our own piece of pain with that error and we used solution described in a different answer (GUnload etc) - without success. The problem was solved when we moved our code from some murky hosting we used - to Amazon EC2. The error stopped immediately. Was it caused by a timeout between our original host and Google servers? We don't know anything except what we did saved us...
I am using the code to place a linkedIn Follow button (generated here https://developer.linkedin.com/plugins/follow-company) on this page, http://new.janeirodigital.com (view Client Testimonials section). However, the buttons sometimes show up and sometimes don't.
I have read a little bit of cross domains issues that may cause this, but I am not able to find a workaround to fix this. If you visit that page in Chrome and see the errors console, you'll see a couple of errors like regarding the linked in button, like:
Unsafe Javascript attempt to access frame with URL mysite.com from frame with URL http://platform.linkedin.com/js/....Domains, protocols and ports must match.
Has anybody experienced this problem before?
Any help appreciated
Daniel
The messages you are seeing in the developer console in Chrome are unrelated to your problem. They are an artifact of the cross-domain communication and as you'll notice, you see them for Facebook and Twitter as well on the same page.
That said, viewing your page I am also seeing intermittent 403s for some of the backend calls that the FollowCompany plugin is making. I have alerted our NOC to the issue and they should be investigating now.
Reviewing your page, it seems you have done everything necessary and are set, so once we fix the operational issue you should be good to go.
My apologies for any inconvenience!
-Jeremy
I just found that this is happening when there are more than one follow button on the page, if you delete the first one and the second shows without problems but the others have the same problem...
Hope this could help your team Jeremy!!
I'm trying to run a multivariate test across 3 pages, google says this should be ok, as long as you use the same section names, it doesn't care about the url so much.
so I have checked in google optimizer, it says all my scripts are set up correctly.
Also the strange thing is it DOES work, it replaces the content, but it never ever saves a cookie, so when you get to the next page, or even just refresh the same page, you might get a different variant.. Which obviously shouldn't happen.
I'm pulling my hair our here, any help would be appreciated.
I had the exact same problem. I've run several tests with GWO and never had this issue. However, with my latest MVT, at first I wasn't seeing GWO even set the cookie. Then, it started setting the cookie but was not able to read the cookie.
Although I am running a sitewide, MVT, I am not running it across multiple domains. However, in order to get GWO to set and read the cookie correctly, I found that I needed to use some of the code required for sitewide tests that span multiple domains. Here is the google article on cross domain tracking:
http://www.google.com/support/websiteoptimizer/bin/answer.py?hl=en&answer=151978
According to the Google WSO API, by default, GWO is setting this property:
gwoTracker._setDomainName("auto");
For whatever reason, it was my experience that this was not happening and by making this call explicitly in my code, it fixed the problem! This call needs to be added to both your Tracking Script and your Conversion Script.
Again, I've never experienced this with any of my other GWO tests, so it was kind of weird to have it happen out of the blue but explicitly making this call fixed this problem for me. Good luck.