As per title, does anyone know why it freezes every 30 seconds?
I figured that it was some sort of timer with Google Maps but cant find any such reference.
To recreate, simply copy into a local file the full html + javascript from:
https://developers.google.com/maps/documentation/javascript/examples/map-simple
Open the local html file and then just move the map around and it will freeze within 30 seconds. Once it unfreezes, it works fine until 30 seconds have elapsed.
Seems to only happen in IE (i used version 11). Note that it doesnt freeze within the Google example page above.
Any help would be appreciated.
This appears to be an issue in the experimental version, currently 3.20.
See versioning in the Developer's Guide
Versioning
The Google Maps API team will regularly update this Javascript API with new features, bug fixes, and performance improvements. All API changes will be backwards-compatible, ensuring that if you launch an application using the currently documented interfaces, that application will continue to work without modification as the API is updated. (Note: experimental features, documented in the Experimental API Reference are not covered by this guarantee. Features that are experimental will be clearly labeled in the API documentation.)
Types of Versions
You can indicate which version of the API to load within your application by specifying it using the v parameter of the Maps Javascript API bootstrap request. Three options are supported:
The experimental version, specified with v=3.exp.
The release version, specified with v=3 or v=3.19.
A numbered version, specified with v=3.18.
If you do not explicitly specify a version, you will receive the experimental version by default. Google Maps API for Work customers who specify a client ID will receive the release version by default.
The experimental version
The experimental version — currently 3.20 — contains the latest features and bug fixes as they are made publicly available. Changes made to the experimental version are not guaranteed to be feature stable. We encourage you to regularly test your applications with the experimental version, which you can do by adding v=3.20 when loading the Maps API. If you like to live on the edge, you can add v=3.exp to always receive the current experimental version with all of its latest features.
I think it has something to do with the security settings (for local files).
Because I hosted the exact same file on github, and it seems to work fine. And the only difference between the two files are their storing location.
If you open the local file, it would says something like internet explorer restricted this webpage from running scripts or activex controls, so I would say it is the security settings for local files.
If you try to run the HTML from a local drive with developer tools on you get the error 'Invalid Argument', in the function below, then you hit f5 to continue and the map eventually renders. Hope this helps.
function dn(a,b){return a.setQuery=b}function en(a,b){return a.background=b}function fn(a,b){return a.tilt_changed=b}function gn(a,b){return a.bounds_changed=b}function hn(a,b){return a.getStatus=b}function jn(a,b){return a.getQuery=b}function kn(a,b){return a.projectionBounds_changed=b}function ln(a,b){return a.border=b}
Related
I've got a problem with Unity installed on Mac OS (Unity 2020.1.16f1 Personal and Mac OS Catalina 10.15.6)
It's look like Unity delete files by itself from my asset folder.
It occurs with both a Firebase (Firebase SDK 7.0.2) and PNG file.
The deletion seems to occur something like each hour (more or less)
However the problem don't happen with all my assets, for exemple with the Firebase SDK it seems that only the file FirebaseCppApp-7_0_2.bundle (and with my png file it happens only with a specific file).
Here's how I get the problem (exemple with Firebase SDK):
I import Firebase SDK I need into Unity (Import Package -> Custom Package and then choose the one I need)
Got this error: "DllNotFoundException: FirebaseCppApp-7_0_2"
Correct this error by going to Security And Confidentiality of my Mac and authorize Firebase to be open (when you download something from internet directly sometimes your Mac ask for this authorization because he don't recognize the developer)
Work perfectly for approximately 1 hour (I can make all changes I want, test my game with the game mode etc ...)
After 1 hour get the error of 2) again (on game mode)
I can fix the problem by reimport only one file from the SDK (FirebaseCppApp-7_0_2.bundle locate in Assets/Firebase/Plugins/x86_64/)
The first time I click play in Game Mode Unity crashes
Go to 3) step and continue
Is someone already get this error ? I've found multiple thread on internet talking about similar bugs (but not exactly the same) but nothing worked for me ...
I found and correct the problem. In fact the problem came from the iCloud which seems to not works correctly with Unity. For some obscur reason, the files which were deleted didn't sync with iCloud, and so when iCloud sent back the project the files were missing. You need to disable automatic sync with iCloud.
Some earlier versions of the Firebase SDK offered to add packages to the Unity Package Manager and would migrate files automatically. I would suggest using only unitypackage integration and trying to undo this migration in the process now. To see if this is the issue, do the following:
close Unity
open Packages/manifest.json and delete the entry for "ScopedRegistries" and remove any lines under "dependencies": { that start with "com.google. Note that Packages is a sibling of Assets (that is, it's next to rather than inside).
for safety, remove any Firebase packages under Assets. This include the folders:
Assets/ExternalDependencyManager, the (old) Assets/PlayServicesResolver, Assets/Firebase, Assets/Parse, Assets/Editor Default Resources/Firebase, Assets/Plugins/Android/Firebase, and Assets/Plugins/iOS/Firebase.
Download the latest Firebase Unity SDK (you can check the release notes here).
open Unity again and add each UnityPackage you need from the SDK. You can usually follow the errors in the console output if you've forgotten everything you're using.
A less likely issue you might be running into is MacOS's stricter behaviour with respect to gate keeper. There's a video here with a workaround, but since you mention the PNG files disappearing I expect that it's the External Dependency Manager.
When you initialize Firebase hosting, it includes a comment in the header of the index.html file that is generated:
<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>
My question has to do with "as needed;" I looked at the docs, and didn't see an explanation.
Probably this means it is supposed to be obvious -- but when you're a beginner, most things aren't!
So, to make my question more concrete:
When might updating the version make a Firebase web app break?
Relatedly, if an app is working, and one does not update for a long
time (many versions/years), does the app remain functioning? Or will it break if not kept current?
Does "as needed" imply "as needed [for access to new features]"?
Finally, is it implied that these changes should be implemented
manually -- by regularly looking up what the latest Firebase version
is, and typing a new version number in index.html -- or is there some
kind of automatic "stay current" workflow/tooling/convention that is
implied?
I realize that there are a number of sub-questions above, but they are all intended to be clarifications of "update as needed," so I think they belong in the same place.
I hope any answers will help other beginners understand the larger issue of when it is appropriate to update the services an app depends upon! Thanks.
Firebase follows what is known as semantic versioning (SemVer) rules.
From semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
That means that the API is guaranteed to stay compatible within minor version (7.x) in your case, but breaking changes may be made in major version (8.0). This means that minor versions (7.x) are used to fix problems, and sometimes add minor features that don't break existing behavior.
With that knowledge, let's see if we can answer your questions:
When might updating the version make a Firebase web app break?
Updating within the same major version (7.x, e.g. 7.5.2 -> 7.5.3, or 7.5.2 -> 7.6.0) should not break your app. There are some exceptions, such as when your code depends on buggy behavior that was fixed, or when there is a mistake in the release. The latter will typically be fixed by the Firebase team as soon as possible, while you'll typically want to roll back to the previous version and update your code in the former case.
Relatedly, if an app is working, and one does not update for a long time (many versions/years), does the app remain functioning? Or will it break if not kept current?
Once a version is published, it remains unmodified. So your app will stay working the way it did when you made it.
Does "as needed" imply "as needed [for access to new features]"?
Two main reasons for upgrading:
To get access to new features.
This is the most obvious reason to upgrade, as it allows you to add new functionality from Firebase to your app. Most often this
To get access to bug fixes.
Bugs may be discovered in the library version you use, and some of those bugs may be security holes. In that case, not updating to a more recent version means that you'll have a known security vulnerability in your app. Key to realize here is the known part: most hackers search for apps with known vulnerabilities, instead of trying to find new vulnerabilities.
Finally, is it implied that these changes should be implemented manually -- by regularly looking up what the latest Firebase version is, and typing a new version number in index.html -- or is there some kind of automatic "stay current" workflow/tooling/convention that is implied?
If you use a tool to build/pack your website, that typically has a way to automatically pull in new versions.
Many developers configure such a tool to automatically pull in new patches (7.5.x) upon every build, while some even pull in new minor release (7.x.x). But there's also a school of thought that prefers to hard-code the exact version number and only upgrade manually by regularly checking.
Either way, it's required to make a new build to upgrade, even in this case. That's a Good Thing™️, as the last thing you want is that your app breaks in production when Firebase accidentally releases a new version with a bug (a rare occurrence, but it has happened). By only including a new version in your build process, you reduce this risk, especially if you run automated tests of your app's functionality as part of the build.
There's no right or wrong answer here, as either can work just fine. It's really up to your own preference.
We are setting up a new version of our app and we are switching from the legacy (v4) GTM SDKs to using the v5 mobile Google Tag Manager via Firebase.
On Thursday and Friday morning I ran some extensive tests on our tracking setup on Android and found a number of bugs in the GTM setup. I fixed them and then republished the app around mid-day on Friday.
On Monday morning (yesterday) I ran some additional tests and none of the fixes that I made worked, in the sense that the data that reached Google Analytics (the ultimate endpoint) showed the same errors from the previous round of testing.
My only conclusion is that the container didn't automatically update over the weekend (according to this, it should update every twelve hours).
I am pretty certain that this is the problem because some of the fixes included updating lookup table variables (we don't pass event category / event action as parameters from the app, these are mapped via two separate lookup tables), and the event category / action values were unchanged in GA in the second round of testing, even though they had been altered in GTM in between.
The documentation is a bit vague on exactly how the update process works - is there a way to debug exactly how to set up GTM in the app to ensure that it will automatically update when the container is republished in the GTM UI?
OK, the answer was pretty simple in the end, but as far as I can tell this is written nowhere in the documentation.
So, all you have to do is not rename the JSON file that you download from the GTM web interface - that's it! Our Android devs had renamed the different versions as gtm_dev.json, gtm_test.json, gtm_prod.json, etc, and this caused the automatic update to fail. That's it!
So if you are googling this error, double-check that your JSON file in the app has not been renamed.
I've just created a feature for our application which generates a powerpoint report from the data a given user has in our system.
In short, the server spawns an instance of google chrome using Selenium's ChromeDriver, and from there scrapes out the charts from our application running in chrome. It was done this way to ensure the charts in the report look exactly the same as they appear in the clients' browsers.
We use Azure Web Apps to host our development and production environments, and while my reporting feature works fine in local environments, it doesn't work once deployed to any other environments, because it depends on chrome being installed, and I can't get it installed in the Azure Web App sandboxed environment.
(you can see this other question of mine for a bit of a reference to where things are going wrong: PowerShell StartProcess: invalid handle )
SO
What I pretty much want to know is, if an Azure Web App environment isn't going to allow me to install google chrome, where should I look next?
It looks like using Service Fabric may allow me to install what I need appropriately (https://learn.microsoft.com/en-us/azure/app-service/choose-web-site-cloud-service-vm), but it seems like a big change to make just to be able to facilitate this small part of the feature.
Another option is to just re-architect the feature so it doesn't depend on the server spawning an instance of google chrome.. but I'd just prefer to avoid that if there's a straightforward way for me to get what I have working.
Ideally, there'd just be a way to get google chrome installed in the given environment, but I've spent a good 10 hours trying to get that to happen now, and it's not looking promising.
There's a couple of solutions which would work - depending on your code and framework dependencies.
IMO - the simplest way would be to build your code in a docker container (that runs the Selenium ChromeDriver) and deploy it either through the container features on Web Apps or run it on demand through ACI (Azure container instances) and have it create the report and drop it in Azure Storage. In a container you have a lot more options - and you have a great amount of options on how to run it. Spinning up an ACI on-demand to do the job can be done in multiple ways (e.g. from Code or through logic-apps or Powershell/Azure automation).
Here are some links on running containers in your App Service:
https://learn.microsoft.com/en-us/azure/app-service/containers/
https://learn.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image
You could start off by building and adding your code from this image: https://github.com/SeleniumHQ/docker-selenium
Other alternatives of course - you could have a VM that you can install and do what you want with on-demand - however - it'd add more management overhead and other implications to think about.
Many options - but in the regual Web App Sandbox - you're limited.
I have found myself this problem with chromedriver.exe needing a real Chrome. As I cannot install Chrome in Azure App Service I am trying a portable version of Chrome. When using the chrome webdriver I tell it where to find the chrome binary.
var options = new ChromeOptions();
options.AddArguments("headless"); // any options you need
options.BinaryLocation = "YOUR CHROME BINARY PATH HERE";
var driver = new ChromeDriver("YOUR CHROME DRIVER PATH HERE", options);
You should be able to copy the chrome portable files as no installation is required. Although it is heavy, 250 MB, because it includes the non portable version inside.
Be sure to use a Chrome version compatible with your ChromeDriver as pointed in the documentation
I created a snapshot view using Rational ClearCase explorer.
After creating it, I set the config specs, environmental variables and later tried compiling my code and got an MVFS error which says:
Unable to determine if the current working directory is in MVFS - no such device or address
When I searched the IBM website for the sake of eliminating this error, I found out that a snapshot view does not use the MVFS !
Why am I getting this error when Snapshot view does not use MVFS?
When this issue got triggered: Actually in our project we were using a ClearCase (8.0.0.7 version). We never had problems when we tried to build our code on the 8.0.0.7 version. It was only after upgrading this version to 8.0.0.15 that the build issue has arisen. The legacy of both old and new ClearCases are baseClearcase
Some more specifications regarding the issue:
The server which we are using is a Windows 2003 server. I am creating a snapshot view in H drive (NTFS drive) as C drive is not available for use in our project, cleaning the previously built files by running the shell script clean_view.sh and then compiling our C code with the ClearCase command clearmake.exe all. Previously we used to follow the same procedure where build used to succeed, but now the same has become an issue.
This question is an extension to the question which I have asked previously. I am re-posting this question as a whole thing again in order to give more clarity about the issue and also for more number of ClearCase experts to chime-in. Kindly do not treat this as a duplicate one or force close it as my issue has not yet been resolved. Also please note that this is the first time I am working with ClearCase.
LINK FOR THE PREVIOUS QUESTION: MVFS error in a snapshot view
Recently there was a development in the solution of this issue !! We escalated this issue to IBM with the help of our client. They suggested us to use Dynamic views and we used them. To our surprise it was working fine and we are able to generate the executables. But the fact still remains that we are not able to use snapshot views !!
NOTE: This comment is just to share my knowledge and experience regarding this issue. :)
While a snapshot view isn't in the MVFS, clearmake has MVFS-specific functionality for build auditing.
You mentioned that the "H" drive contained the snapshot view, is H:
A local or network drive?
A drive letter created via SUBST? In this case, is the parent drive local?
Do builds in dynamic views still work?
Does the C drive exist? Is it remapped in a Terminal Server/Citrix environment?
A caveat: Windows Server 2003 is nearly a year past MICROSOFT'S end of extended support. I would recommend updating the server environment as soon as possible.
Truthfully, issues where a process fails, and the ONLY change is the ClearCase version are usually best handled by contacting IBM instead of using this venue. Not trying to shill or anything, but if it's a clearmake bug, it has to go there anyway...
Additional questions:
If the C: drive is inaccessible on the system, which is what "can't even get the properties" in the comment seems to infer, where is the OS installed? Where does %SYSTEMROOT% point?
If it worked on a different drive, what's different between those 2 drives (H: Failed and R: worked)