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...
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'm facing problems with GTM , ' the still running problem ' to be precise.
I know this is a known issue in GTM , as it is caused by using GA variable in the GA-CODE box or vice versa.
But in my case, it should have been done correctly (see screenshots)..
Are there other things that cause tags to hang ?
I tried both ways : Using a GA Variable and removing it and using the override settings box and filling in the UA-######-1 code..
Thanks in advance
This is an unfortunate "feature", but if you try to load a Google Optimize container that doesn't respond (due to not existing or due to not being active), the container returns a 404 status error, but the ga() queue keeps on trying to load it.
This means that all subsequent ga() calls are put on hold while the queue tries to load the Optimize container. Since there's no timeout for this, all Google Analytics calls that follow the Optimize require command will fail to fire, and GTM will show "Still running" for these hits.
I have reported this as a bug.
Thanks to Simo ,
the problem was a not existing Optimize ID in another tag!
Very strange that this blocks some other tags that have nothing to do with it , but it did fix the issue.
Since evening of last Wednesday (March 15, 2017) I have noticed that the google analytics script is not being requested by my website consistently. When the script does load, the tags are not firing - for example for button clicks.
Is anyone else having this issue? I have searched around for threads regarding any malfunction on Google's side and could not find any. Google recently had an issue with their captcha which is why I am thinking this is an issue on their side.
To note, the site is built on a CMS and the tag manager code snippet is inherited on every page. This snippet has not been altered in the time surrounding March 15th.
Edit: Moving the code snippet from head to body creates consistent behaviour - gtm.js and analytics.js are loading and the tags are firing and registering in GA.
Check for not using dataLayer = [{...}] declaration after script part of container snippet in your pages code. This declaration should be used only before container snippet.
First thing to check, which you may have already done, is the position of the two code snippets used for implementation. I always position the <script> tag first in the <head>. Also, make sure the <noscript> tag is the first tag rendered in the <body>.
I had a similar issue once. My tags would inconsistently fire. After checking the console log, I found that JQuery was being declared toward the bottom of the <body>. When I moved the JQuery tag to the <head>, the issue was resolved. I can't imagine that you're issue is related, because my issue was due to a mistake by a developer. Nonetheless, check your console log to see if you notice any errors. It may help you determine the root of the problem.
One other thing to try is the Tag Assistant Chrome extension. Run it on your website, and it will run checks on your implementation.
Hope this helps! Let me know if you have further questions.
We are adding openfire fastpath chat to our site. It will determine and indicate when live chat is available or not and display an appropriate image to indicate the current status and links for each state.
The javascript call hit's a function that is on another box and this function uses document.write to output the html to the page. I know there is a delay because it is making the request to another server and waiting for a result to be returned. The pause here is about a half second, but causes the rest of the page load to be held up.
Has anyone experience a similar issue or offer any tips for getting this to load synchronously somehow. I tried putting this into an aspx ajax panel, but that seemed to cause other issues.
I used an iframe that is the only thing I could find that seemed to work.
I have an asp.net C# .net 3.5 page which contains several user controls. I am noticing that sometimes the html loaded on the browser is incomplete. It seems to get cut-off.
Any suggestions on how to troubleshoot whats the root cause?
This can be symptomatic of server errors or proxy problems. I would use Fiddler to check what's going back and forth between your browser and the server. If you are getting any 500 (server error) response codes, that would be a good place to look.
Another thing to check would be javascript errors on the page, because depending on what your javascripts are doing, errors can prevent loading of other content in some cases.
womp probably has most of the bases covered, but the other angle that can lead to issues like this would be exceptions getting eaten but causing processing to stop, thereby sending half the page or somesuch.
Verify that your HTML is being written to the page by viewing the source code of the page after it loads. My guess is that the HTML that is being output is invalid, and that the browser isn't able to properly display it. Make sure all your HTML tags are properly closed and balanced.
It could also be an issue with the request being ended midway through. Try removing one control at a time from the page and see if the situation improves. If it does, you'll know which control is to blame.
It is quite unlikely that it is the same problem, but I had that happen before where the page had a custom filter attached to response.filter which reformatted the output to fix up some dotnet SEO problems. And the one we wrote had a bug where one regular expression consumed a bit too much copy in some instances and broke the output