Sometimes Initialization of Google Earth Plugin fails in IE10 - google-earth-plugin

This is my code for the initialization of google earth plugin.
Sometimes Initialization of Google Earth Plugin fails in IE10(I have it in compatability mode) IE7 Standards. This error happens only in IE and no other browser.
90% of the time createInstance() method creates the google earth plugin instance and control goes to mygeeEarthPluginInitCb() method but few times mostly after restarting the machine or after few hours of inactivity if I load the page createInstance fails and control goes to geeEarthPluginFailureCb() method.
This is causing an error page, a very intermittent one.
function geeInit() {
alert("google.earth.createInstance : Start");
google.earth.createInstance(geeDivIds.map, mygeeEarthPluginInitCb,
geeEarthPluginFailureCb, earthArgs);
alert("google.earth.createInstance : End");
}
function mygeeEarthPluginInitCb(object) {
alert("Success mygeeEarthPluginInitCb: Inside");
geeEarthPluginInitCb(object);
gex = new GEarthExtensions(ge);
createSearchResultsMarkers(null, 'results');
var lookAt = ge.createLookAt('');
lookAt.setLongitude(Number('-73.784190'));
lookAt.setLatitude(Number('42.643446'));
lookAt.setRange(25000.00);
ge.getView().setAbstractView(lookAt);
initRadSearchValsOnLoad();
}
function geeEarthPluginFailureCb(message) {
alert("Failure geeEarthPluginFailureCb: Inside" + message);
if (google.earth.isInstalled()) {
} else {
var result = confirm('Google Earth Plugin is not'
+ ' installed.Please download and install it.');
if (result == true) {
window.location.href = 'install.html';
}
}
}

Remove all the alert lines, e.g.
alert("google.earth.createInstance : Start");
and
alert("google.earth.createInstance : End");
alert is a special method that blocks execution and user interaction - it could well be that it is blocking the initialisation of the plugin. This is something I have seen before.
Perhaps try using the console, or else outputting data to the document in some way that avoids blocking. e.g.
console && console.log("google.earth.createInstance, "End");

Google acknowledged the issue and mentioned they are working on a fix.
For right now there is a temporary fix below is the shorter version of Google's response.
******** Start Google's Response *************
"We have been able to reproduce this issue, intermittently. It is now pending additional investigation for the Google Earth client team, to find the root cause here. Unfortunately, it is not possible to provide an estimate for a deadline when this will be fixed. This issue definitely has a high priority since it impacts all Google Earth users with custom globes (GEE, and GME), and we have let the team know that this is now critical for your applications.
The only workaround that we can see, right now, is to refresh the page when the plugin fails to load (or you could do that programmatically: implement a timeout, and if after 5 seconds, the Earth API has not yet loaded, reload the plugin, or refresh the page). You could also consider using the Google Earth client, but I'm not sure if this is something that would be applicable to your use case."
**********End Google's Response ***************

Related

Youtube video sometimes returns not available

On a wordpress website we are showing some video's on product pages.
Without any regularity there is a "video not available" message. I was hoping we could get some help figuring out any way this is possible. Below is the error we are getting, which doesnt provide a lot of inofrmation.
I already kind of ruled out the copyright to be the issue, since this is not constantly and happens at random moment & intervals.
"debug_error": "{\"errorCode\":\"auth\",\"errorDetail\":\"0\",\"errorMessage\":\"Deze video is niet beschikbaar\",\"yk\":\"\",\"xI\":\"0;a6s.0\",\"aB\":2}",
I've had to debug this issue for a week since it happened so randomly. No idea what causes it, but what I did to get around it was altering the onReady event function to check the errorCode, and then stop the video before we call the play event.
function onPlayerReady(event) {
var data = event.target.playerInfo.videoData;
if (data.errorCode == "auth") {
event.target.stopVideo();
}
event.target.playVideo();
}
onPlayerReady is what we call on the onReady event, as in options.events.onReady.
This only does the check once, since I did not want to hammer Youtube if a video doesn't load.
It is a very aggravating problem and I can't seem to find any more info on it either. An auth error would point to something authentication related, but we get this with videos we own and specifically enabled for embedding, and as far as I know the iframe api does not require any api keys to use.

Recaptcha V3 assets cause Pagespeed issues - how to defer

We're currently using Google Recaptcha V3 across the public-facing portions of our site - while doing Pagespeed Insights performance testing (Mobile), Google themselves is reporting unused/undeferred CSS as a problem on their own Recaptcha css file:
Full resource address is:
https://www.gstatic.com/recaptcha/releases/[...]/styles__ltr.css (so it is clearly coming from a subsequent Google Recaptcha script request)
We are including the original Google recaptcha script with the 'defer' attribute set - not sure what else we can do to cause this css to be deferred such that Pagespeed does not complain about it. Can't find any documentation on the Google Recaptcha site itself to help with this issue.
Does anyone know how to defer this CSS to improve page load time? Not sure if this is somehow a Mobile specific issue, as Pagespeed doesn't report it at all on Desktop.
Firstly, bear in mind that 'remove unused CSS' is more of a guidance point (provided it isn't render blocking), it is indicating that it is wasted bytes (which it actually isn't if recaptcha triggers, as it then needs that CSS to render the image 'are you human check' etc.)
Although I can't give you an ideal answer as it is code you have no control over, I can give you two ways to test it's impact / whether it is actually a problem and a 'hack' to get around the load order.
Test using applied throttling
Simulated throttling can cause unexpect behaviour sometimes, which is what the Page Speed Insights website uses.
If you use the browser audit (which uses the same engine - Lighthouse) to run the tests you have an option to change the throttling from simulated to applied.
Although your score will change (applied throttling is less forgiving than simulated throttling), you get a much more realistic order of events as the latency and slowdown is 'real' vs making best guesses based on loading the page at full speed and applying formula's to guess load times.
Open Dev Tools in Chrome (F12) -> Audits -> Throttling -> set to Applied Slow 4G, 4x CPU Slowdown. -> Run Audits.
See if the problem persists when using this way of assessing page speed.
If it does, a workaround / test for real world performance is as follows:-
Force the script to load after an amount of time (the hacky way!)
This is not an ideal solution but it is good for testing and as a last resort if it does actually slow down your website key load times.
Insert the script dynamically after 5 seconds.
(please note the below code is untested and is likely to not work, it is for illustration only to point you in the right direction. It is highly probable that you don't need the script.onload section and can include that normally)
setTimeout(function(){
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.onload = function() {
grecaptcha.ready(function() {
grecaptcha.execute('_reCAPTCHA_site_key_', {action: 'homepage'}).then(function(token) {
...
});
});
}
script.src = "https://www.google.com/recaptcha/api.js?render=_reCAPTCHA_site_key";
head.appendChild(script);
}, 5000);
We can use IntersectionObserver to defer Recaptcha script.
var io = new IntersectionObserver(
entries => {
console.log(entries[0]);
if (entries[0].isIntersecting) {
var recaptchaScript = document.createElement('script');
recaptchaScript.src = 'https://www.google.com/recaptcha/api.js?hl=en';
recaptchaScript.defer = true;
document.body.appendChild(recaptchaScript);
}
},
{
root: document.querySelector('.page-wrapper'),
rootMargin: "0px",
threshold: 1.0,
}
);
io.observe(initForm);
We can load the reCaptcha v3 script once after an initial scroll on load:
var fired = false;
window.addEventListener('scroll', function () {
let scroll = window.scrollY;
if (scroll > 0 && fired === false) {
var recaptchaScript = document.createElement('script');
recaptchaScript.src = 'https://www.google.com/recaptcha/api.js?render=Your_SITE_KEY';
recaptchaScript.defer = true;
document.body.appendChild(recaptchaScript);
fired = true;
// console.log('On scroll fired');
}
}, true);
Code Example:
https://codepen.io/iamrobert/pen/NWazNpd
Page Speed Insight Score

Google Play Cross App Scripting Vulnerability: How do I protect calls to evaluateJavascript?

My app is caught up in Google's Cross App Scripting security warning and I can't seem to get a version of the app that doesn't trigger Google's warning.
The majority of the functionality is a WebView wrapper for a web app. That's where the warning is.
I think I've followed the directions in Google's tutorial for Option 2, which are as follows:
1. Update your targetSdkVersion.
It has to be above 16 and I've done that.
2. Protect calls to evaluateJavascript
The WebView does accept URL's from Intents, but those are checked ahead of time to always be trusted. And all external URLs that might appear inside the app are opened externally, i.e. in Chrome.
3. Prevent unsafe file loads
The WebView never opens file:// URIs.
The code below is the relevant section from the class and method that Google is indicating has a problem. I think I've correctly filtered out all code paths there so that the only URIs that open would be my own domain.
I've already been through two levels of Google support and all they say is to follow the directions in their tutorial. I think I've done that:
https://support.google.com/faqs/answer/9084685
rootUrl = "https://example.com"
Intent intent = getIntent();
if (intent.getStringExtra("action_url") != null) {
if (intent.getStringExtra(NotificationIntentService.NOTIFICATIONS_DESTINATION) != null) {
myWebView.loadUrl(rootUrl + intent.getStringExtra(NotificationIntentService.NOTIFICATIONS_DESTINATION));
} else if (
intent.getStringExtra("action_url").matches("^https://example.com/")) {
myWebView.loadUrl(intent.getStringExtra("action_url"));
}
} else {
if (retrieveHasRegistered(context)) {
myWebView.loadUrl(rootUrl + "/android?registered");
} else {
myWebView.loadUrl(rootUrl + "/android");
}
}
}

Google reCAPTCHA response success: false, no error codes

UPDATE: Google has recently updated their error message with an additional error code possibility: "timeout-or-duplicate".
This new error code seems to cover 99% of our previously mentioned mysterious
cases.
We are still left wondering why we get that many validation requests that are either timeouts or duplicates. Determinining this with certainty is likely to be impossible, but now I am just hoping that someone else has experienced something like it.
Disclaimer: I cross posted this to Google Groups, so apologies for spamming the ether for the ones of you who frequent both sites.
I am currently working on a page as part of a ASP.Net MVC application with a form that uses reCAPTCHA validation. The page currently has many daily users.
In my server side validation** of a reCAPTCHA response, for a while now, I have seen the case of the reCAPTCHA response having its success property set to false, but with an accompanying empty error code array.
Most of the requests pass validation, but some keep exhibiting this pattern.
So after doing some research online, I explored the two possible scenarios I could think of:
The validation has timed out and is no longer valid.
The user has already been validated using the response value, so they are rejected the second time.
After collecting data for a while, I have found that all cases of "Success: false, error codes: []" have either had the validation be rather old (ranging from 5 minutes to 10 days(!)), or it has been a case of a re-used response value, or sometimes a combination of the two.
Even after implementing client side prevention of double-clicking my submit-form button, a lot of double submits still seem to get through to the server side Google reCAPTCHA validation logic.
My data tells me that 1.6% (28) of all requests (1760) have failed with at least one of the above scenarios being true ("timeout" or "double submission").
Meanwhile, not a single request of the 1760 has failed where the error code array was not empty.
I just have a hard time imagining a practical use case where a ChallengeTimeStamp gets issued, and then after 10 days validation is attempted, server side.
My question is:
What could be the reason for a non-negligible percentage of all Google reCAPTCHA server side validation attempts to be either very old or a case of double submission?
**By "server side validation" I mean logic that looks like this:
public bool IsVerifiedUser(string captchaResponse, string endUserIp)
{
string apiUrl = ConfigurationManager.AppSettings["Google_Captcha_API"];
string secret = ConfigurationManager.AppSettings["Google_Captcha_SecretKey"];
using (var client = new HttpClient())
{
var parameters = new Dictionary<string, string>
{
{ "secret", secret },
{ "response", captchaResponse },
{ "remoteip", endUserIp },
};
var content = new FormUrlEncodedContent(parameters);
var response = client.PostAsync(apiUrl, content).Result;
var responseContent = response.Content.ReadAsStringAsync().Result;
GoogleCaptchaResponse googleCaptchaResponse = JsonConvert.DeserializeObject<GoogleCaptchaResponse>(responseContent);
if (googleCaptchaResponse.Success)
{
_dal.LogGoogleRecaptchaResponse(endUserIp, captchaResponse);
return true;
}
else
{
//Actual code ommitted
//Try to determine the cause of failure
//Look at googleCaptchaResponse.ErrorCodes array (this has been empty in all of the 28 cases of "success: false")
//Measure time between googleCaptchaResponse.ChallengeTimeStamp (which is UTC) and DateTime.UtcNow
//Check reCAPTCHAresponse against local database of previously used reCAPTCHAresponses to detect cases of double submission
return false;
}
}
}
Thank you in advance to anyone who has a clue and can perhaps shed some light on the subject.
You will get timeout-or-duplicate problem if your captcha is validated twice.
Save logs in a file in append mode and check if you are validating a Captcha twice.
Here is an example
$verifyResponse = file_get_contents('https://www.google.com/recaptcha/api/siteverify?secret='.$secret.'&response='.$_POST['g-recaptcha-response'])
file_put_contents( "logfile", $verifyResponse, FILE_APPEND );
Now read the content of logfile created above and check if captcha is verified twice
This is an interesting question, but it's going to be impossible to answer with any sort of certainly. I can give an educated guess about what's occurring.
As far as the old submissions go, that could simply be users leaving the page open in the browser and coming back later to finally submit. You can handle this scenario in a few different ways:
Set a meta refresh for the page, such that it will update itself after a defined period of time, and hopefully either get a new ReCAPTCHA validation code or at least prompt the user to verify the CAPTCHA again. However, this is less than ideal as it increases requests to your server and will blow out any work the user has done on the form. It's also very brute-force: it will simply refresh after a certain amount of time, regardless of whether the user is currently actively using the page or not.
Use a JavaScript timer to notify the user about the page timing out and then refresh. This is like #1, but with much more finesse. You can pop a warning dialog telling the user that they've left the page sitting too long and it will soon need to be refreshed, giving them time to finish up if they're actively using it. You can also check for user activity via events like onmousemove. If the user's not moving the mouse, it's very likely they aren't on the page.
Handle it server-side, by catching this scenario. I actually prefer this method the most as it's the most fluid, and honestly the easiest to achieve. When you get back success: false with no error codes, simply send the user back to the page, as if they had made a validation error in the form. Provide a message telling them that their CAPTCHA validation expired and they need to verify again. Then, all they have to do is verify and resubmit.
The double-submit issue is a perennial one that plagues all web developers. User behavior studies have shown that the vast majority occur because users have been trained to double-click icons, and as a result, think they need to double-click submit buttons as well. Some of it is impatience if something doesn't happen immediately on click. Regardless, the best thing you can do is implement JavaScript that disables the button on click, preventing a second click.

Meteor: send message to user at hot code push

How can I let the user know when they are getting a hot code push?
At the moment the screen will go blank during the push, and the user will feel it's rather weird. I want to reassure them the app is updating.
Is there a hook or something which I can use?
Here's the shortest solution I've found so far that doesn't require external packages:
var ALERT_DELAY = 3000;
var needToShowAlert = true;
Reload._onMigrate(function (retry) {
if (needToShowAlert) {
console.log('going to reload in 3 seconds...');
needToShowAlert = false;
_.delay(retry, ALERT_DELAY);
return [false];
} else {
return [true];
}
});
You can just copy that into the client code of your app and change two things:
Replace the console.log with an alert modal or something informing the user that the screen is about to reload.
Replace ALERT_DELAY with some number of milliseconds that you think are appropriate for the user to read the modal from (1).
Other notes
I'd recommend watching this video on Evented Mind, which explains what's going on in a little more detail.
You can also read the comments in the reload source for further enlightenment.
I can image more complex reload logic, especially around deciding when to allow a reload. Also see this pacakge for one possible implementation.
You could send something on Meteor.startup() in your client-side code. I personally use Bert to toast messages.

Resources