I was playing with some WebGL tutorials and, for no reason, WebGL just stopped working. I even loaded an untouched WebGL HTML page that I downloaded from the web that worked fine before. When I FTP that same exact code to my web server and load it, it works fine. Two questions...
Why would WebGL all of a sudden just stop working locally across ALL browsers?
Why would WebGL HTML code run fine online, but not locally?
I should also mention I restarted my computer, uninstalled/reinstalled Chrome and Firefox, and cleared all my internet cache.
Thanks so much for all your wisdom!
Found the problem. To prevent a local page from accessing your whole hard
disk drive, each local file:// URI is its own domain, which means that
local textures are always treated as cross-domain. In Firefox, I was able to get around this by modifying the about:config and setting security.fileuri.strict_origin_policy to false
Easiest way to work around this problem:
Use some IDE like Netbeans or Visual Studio to run your application. They use a local server automatically, so you don't have to run it on your own server or mess around with your browsers. Letting browsers access local data is more or less a security issue.
Related
I am running Linux Mint 17.1 (Rebecca)
on my Dell 4x Intel(R) Core(TM) i3-5005U CPU.
I have done X3D in a viewer in the past, but am now
try to do X3DOM in a Google Chrome v42 browser.
I can, for example display
examples.x3dom.org/example/x3dom_helloWorld.xhtml
from x3dom.org website. But when I copy locally to my machine
and try to view I get
"XMLHttpRequest cannot load file:///home/andrewmneiderer/src/Web3D/X3DOM/x3dom.swf. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource."
Has anyone seen this error and have suggestions on what to do?
I wonder why this is not stated in the current documentation, but I remembered that I read it. You can find it in the documentation of previous versions http://x3dom.org/download/1.5.1/docs/html/notes/platforms.html#chrome
Recent releases of Chrome require you to enable WebGL. Please use the
following command parameters when launching chrome:
--enable-webgl
--use-gl=desktop
--log-level=0
--allow-file-access-from-files
--allow-file-access
The last two options enable the browser to load textures from disk. You will need this if you are developing your site
locally.
Furthermore there is an option --disable-web-security which has been mentioned here: http://x3dom.org/docs-old/notes/cors.html#chrome
Besides from that, I think you should try to get a machine with native WebGL support since this Flash version of X3DOM is just a fallback method which might lack the performance features of the native version.
Chrome on all systems (by default) does not enable loading of resources from the local disk - even when the parent HTML comes from the local disk. Firefox, IE, and (I think) Safari all allow local file loading. If you need to load X3D files using X3D from your local disk, then you need to implement a local web server. It is not necessary to run a full-blown Apache server. Google 'local web server' for various options.
Extremely often, in all kinds of various MVC3/4 apps I debug in VS2012 on my home machine, after pressing F5 to start debugging and open the configured start page in Chrome, it can take several - up to ten - minutes before becoming active.
I have no long startup procedures that load caches or generate code etc. and the same app will start instantly on my office machine. Quite often it will do so on my home machine as well, but this slow starting seems to come about after some hours of debugging, and possibly certain operations. Restarting VS doesn't seem to help, neither does killing IIS Express.
We were faced with an identical scenario recently where attaching the application to the debugger resulted in each page load taking about 10 minutes each, but running without debugging or in the QA environment worked fine.
The problem turned out to be that log4net was configured to use a network path for storing log files, a path that was unavailable from our local setup. This resulted in multiple attempts at accessing a remote path (once for each class being set up with Spring .Net) that didn't exist (and hence log4net threw an exception in each case).
But this should impact you out of the box, and shouldn't increase with time..
I am fairly new to ASP, so if anything doesn't make sense, or you think, "WHY WOULD YOU DO THAT?", it's becasue I really didn't know.
So the issue is that I created a Website using Visual Studio 2012 Express for Web. It was an ASP.NET MVC. I have spent over a week, working on this, doing testing and getting everything to work and look correctly. So I started the process of deploying it. I followed a couple guides, and felt like I did everything correctly.
Right now I am only trying to test my website on , and my first screen shows up. This screen is a "login" screen of sorts and is supposed to connect to my Access Database to check to see if a user should be admited to the next screen. But clicking the "Submit" button doesn't even open the Database. All of this works fine when I run it in Visual Studio.
What can I do to get this working?
Some steps I have tried and failed at:
-Redeploying
-Changing location of the Access DB
-I started to try to install configure and convert my Access Database to SQL Server, but I haven't been able to get that to work either.
If anyone has any suggestions, please let me know. If you need code examples or IIS settings, I will get them to you as fast as I can, but please help me because I don't want to have lost over a week of work.
Thanks,
D
Edit: After taking the suggestion from HansUp, it lead me to some other search terms that lead me to http://www.iis.net/learn/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/using-classic-asp-with-microsoft-access-databases-on-iis. I am using a 64-bit machine, and my application pool in IIS was not set to run 32-bit applicaions which when using Access ODBC drivers that are 32-bit casue a problem.
Set the IUSR account to Read/Write for the DB file and folder where the DB file is located.
Then, seeing as I was using a 64-bit machine, and the Access ODBC drivers that were being used were 32-bit, I had to set "Enable 32-bit Applications" to "true" in IIS, for the Application Pool that my site was using.
This is a link to where I found the 64-bit 32-bit solut
http://www.iis.net/learn/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/using-classic-asp-with-microsoft-access-databases-on-iis
YayMyLife.com is my first Rails site. I am using Apache/2.2.8 (Ubuntu) Phusion_Passenger/2.2.2 .
The site works fine on Linux/Mac/Phones. However, it does not load on any browser on XP. This behavior is also found on other XP machines. The browser seems to wait for more content and it times out. I have checked headers with Live HTTPHeaders (the headers look okey) and also flushed DNS cache on XP box.
Can you please help me fix the problem?
Are you sure it doesn't work? I just tried it using IE7 and Firefox 3 within one of my Windows XP virtual machines and the site loads fine. I get a JavaScript error in IE but not in Firefox.
I got browser shots for those who are interested in solving this case:
http://browsershots.org/http://www.yaymylife.com/
This gentleman was on #rubyonrails previously and asked the same question, with little feedback
What is the error that you are getting? If you look at all the browsers, they haven't finished loading ... could it be excessive load on the server?
Have you tried getting a Windows machine and trying to test it? If so, what is the error (with screenshot and/or stack trace from your log).
If it was a problem with rails, it would not load on any browser, if it was a css problem it would give you crap on the screen.
This looks to be an excessive load problem and something that you should try and address by looking at the web server end at the amount of time it takes to load the page and whether you need some sort of template caching or to improve the performance of DB queries that are running.
I started using Mongrel instead of Passenger and this problem is fixed. Thanks to everybody who took interest; esp. Omar Qureshi
Our web site (running Rails) freezes IE6 nearly every time. The same code, deployed on a different server, does not freeze IE6. Where and how should we start tracking this down?
You need to determine the difference between them, so I'd start out with the following:
curl -D first.headers -o first.body http://first.example.com
curl -D second.headers -o second.body http://second.example.com
diff -u first.headers second.headers
diff -u first.body second.body
Might be a communication problem. Try wireshark against the server that freezes and the server that doesn't freeze. Compare the results to see if there is a difference.
Narrow down the problem. Start cutting out code until IE6 doesn't freeze. Then you might be able to figure out exactly what is causing the problem.
I've been having this problem today on an AJAX-heavy site. I think I've narrowed the problem down to the server having GZIP compression turned on. When the GZIP was turned off on our server, IE6 loaded the page without freezing at all. When GZIP is turned on, IE6 freezes/crashes completely.
I also noticed that images were being served with GZIP from our server, so I disabled that for images and this solved the problem with IE6 freezing/crashing. Now the server uses GZIP only for .js, .html, and JSON.
Try both in IE6 on different machines, preferably with as few addons as possible such as spyware blockers or Google Toolbars...
Use Firefox with Firebug to compare the HTTP Headers in the Request and Response from both servers.
You can also try : http://projects.nikhilk.net/WebDevHelper/Default.aspx
That installs in IE and may help you in troubleshooting network issues and such. You may be able to see exactly when and where it freezes in the request/response by using its tracing features.
Is the freezing happening on your development server or your production server? Weather your developer server locks up IE6 or not isn't that big of a deal, but if your production server fails to kill IE6 you might have a problem!
:-P
Perhaps some more info that will help you.
We had the same problem and narrowed it also down to the GZIP compression. The key was that we had gzip compression on for our ScriptResources, which also deliver the javascripts used by the controls in our .NET page.
Apperently there is a bug in IE6 that causes is to freeze, we believe that the browser receives the files and parses them before unpacking them, which causes the freeze.
For now we have turned off the gzip compression, but as we have a large number of files provided through the ScriptsResource manager we need a different solution.