Hi. I have a problem with my current site that has me totally stymied.
I have implemented a javascript flipbook (like an ibook) on my website. It works in Firefox, Opera, Mac, on the iPad, etc., but not on Chrome Windows 7. In Chrome Windows 7, when I click, the page turns, and then the application resets back to the original image. In Firefox, however, it works just fine.
I have scoured the code to find the solution, troubleshooted from different angles, but can't solve the problem.
You can view the site in its current condition here : http://www.cambrianvacation.co.uk/powersb
I have only just begun working on this site, and the flipbook just has dummy content, purely for the purpose of getting it to work, so please excuse that.
If anyone can diagnose the problem, I would be very grateful.
P.S. I have only been studying Javascript for a few months, and although I have a basic understanding, it's not enough to resolve this.
It works perfectly fine for me in Windows 7 + Chrome.
Since Chrome is quite aggressive in it's caching policies, you might as well clear Chrome's cache and try again.
I have the same issue, if you go to their website over here: http://flippingbook.com/help/publisher-2/faq/launching-local-publication-in-google-chrome/ they have a guide on how to fix this issue. It is very not handy at all though because it will be fixing the problem for you only not for whoever visits your website.
Related
I have a website: www.OnCampusChef.com
it is supposed to play a short video clip in the background using a jQuery Youtube Player plugin, and it does work on most people's computers. In fact, it even works on safari on my macbook pro. However, for some reason I can't get it to play on my google chrome. I have tried restarting my computer, uninstalling chrome, clearing the cache and browser history, making sure the javascript in my browser has been enabled, but to no avail.
Any insights as to what could be causing the problem?
The weird part is that it works just fine on my other browsers and even on my localhost.
Thanks in advance!
I've had a similar issue recently with a web-site i'm building (lisa-lab.com). What I've discovered is that the problem occurs only on Google Chrome for Mac, and only for videos shorter than 10 seconds. I've been able to narrow it down to the Accept-Ranges: bytes header, but I'm still uncertain as to why that fails for short videos, but works fine on larger ones. I think I may have to tweak my Apache settings a little.
Anyway, hopefully this helps you troubleshoot your issue.
My problem may seem a bit vague (it is to me too), but here is my attempted explanation of it.
A few months ago, I implemented PDF.js in my web application. It was really useful, and I am using it for interactions with my clients.
Suddenly, last week, my clients reported to me "Aw, Snap" messages in Google Chrome on their PCs when they try to launch PDF.js. I have an iMac and two PCs at home, so I decided to test this out.
When I used Google Chrome on my iMac to launch PDF.js, I found it worked fine.
When I used Google Chrome on my first PC to launch PDF.js, I found it worked fine.
When I used Google Chrome on my second PC to launch PDF.js, even though it previously worked, it kept crashing and showing me "Aw, Snap" messages.
This was weird. I tried removing all the extensions, clearing the cache, clearing the LocalStorage, but nothing seemed to fix the problem.
I then realised, after some communication with my clients, launching PDF.js in Safari, Torch, Opera or Firefox on any operating system worked perfectly fine.
Why would this happen? I am using the web viewer in PDF.js. I also tried with the basic hello world example, but that broke as well (which I now find really weird), so I suspect there's something wrong with the rendering engine.
I also tried including the compatibility.js file after building the source, but with no avail.
Is there any known bug which causes Google Chrome tabs to crash?
Yes, I got it now.
From https://github.com/mozilla/pdf.js/issues/4104, I found the answer (thanks Rob and PDF.js dev team!). Take a look yourself!
I'm only posting this here so that anyone who stumbles upon this post with a similar problem can be helped (as this error took me quite a while to figure out).
Unfortunately, this does not seem to be the case. We've tried the latest version of pdf.js from github, also tried Chrome 33 (stable) which should have their V8 fix included and it still crashes. Also, tried the pdf.js commit mentioned in github thread (4ce6cb8 - https://github.com/mozilla/pdf.js/commit/4ce6cb8b0fa9db948516b2b738fa1503cf0ef90e) - still crashes. Also tried latest Chrome Canary available on 19/03/2014 - crash is there.
We can provide the WinDbg memory dump if it's of any help.
PS: sorry, this should be the answer to Rob W thread right above but I cannot add it there due to 0 reputation.
My problem may seem a bit vague (it is to me too), but here is my attempted explanation of it.
A few months ago, I implemented PDF.js in my web application. It was really useful, and I am using it for interactions with my clients.
Suddenly, last week, my clients reported to me "Aw, Snap" messages in Google Chrome on their PCs when they try to launch PDF.js. I have an iMac and two PCs at home, so I decided to test this out.
When I used Google Chrome on my iMac to launch PDF.js, I found it worked fine.
When I used Google Chrome on my first PC to launch PDF.js, I found it worked fine.
When I used Google Chrome on my second PC to launch PDF.js, even though it previously worked, it kept crashing and showing me "Aw, Snap" messages.
This was weird. I tried removing all the extensions, clearing the cache, clearing the LocalStorage, but nothing seemed to fix the problem.
I then realised, after some communication with my clients, launching PDF.js in Safari, Torch, Opera or Firefox on any operating system worked perfectly fine.
Why would this happen? I am using the web viewer in PDF.js. I also tried with the basic hello world example, but that broke as well (which I now find really weird), so I suspect there's something wrong with the rendering engine.
I also tried including the compatibility.js file after building the source, but with no avail.
Is there any known bug which causes Google Chrome tabs to crash?
Yes, I got it now.
From https://github.com/mozilla/pdf.js/issues/4104, I found the answer (thanks Rob and PDF.js dev team!). Take a look yourself!
I'm only posting this here so that anyone who stumbles upon this post with a similar problem can be helped (as this error took me quite a while to figure out).
Unfortunately, this does not seem to be the case. We've tried the latest version of pdf.js from github, also tried Chrome 33 (stable) which should have their V8 fix included and it still crashes. Also, tried the pdf.js commit mentioned in github thread (4ce6cb8 - https://github.com/mozilla/pdf.js/commit/4ce6cb8b0fa9db948516b2b738fa1503cf0ef90e) - still crashes. Also tried latest Chrome Canary available on 19/03/2014 - crash is there.
We can provide the WinDbg memory dump if it's of any help.
PS: sorry, this should be the answer to Rob W thread right above but I cannot add it there due to 0 reputation.
We just got hold of a Samsung Galaxy S4 for testing our mobile website (running latest Touch-Wiz Android 4.2.2 - build JDQ39).
Straight away we noticed some major issues in our site. After some investigation, I discovered that this seems to be due to window.setInterval(fn, repeatInterval) not repeating, and only calling the passed function once.
Please note, there probably isn't a problem with our usage of setInterval, as our code works on all our other devices (lots), the chrome browser on the same device, and on desktop browsers.
I've searched, but can't find any mention of this problem. It seems bizarre to me that such a major bug would not have generated more noise.
My question is: Has anyone else seen this problem? Is it the default browser on 4.2.2, or a Touch-Wiz specific problem? Did you find an elegant work-around?
I've come up with a work-around using self-perpetuating setTimeout(s) but it's a bit nasty, and I'd rather not have to do it like that.
Turns out it wasn't actually setInterval's fault at all. Weirdly enough eval.call(window, 'some js'); seems to stop all intervals from working on this particular browser. Really don't understand how. This is the only phone we've seen it on - it doesn't happen on the stock browser on the S3 (Android 4.2.1).
P.S. The only reason we're doing eval.call is to allow make banner ads which use document.write to add scripts in a one page dynamic loading app. I'd much rather it wasn't there.
Recently I started modifying our website to be cross platform compatible. Our site was coded to work in IE 6 initially and upgraded to work IE7 then all code changes has stopped. The site was used in compatibility view until now. We are now changing the site to work for chrome, firefox, safari, and IE7(we have clients still using IE7 sadly) and above.
Quickly we noticed the javascript coding wasn't coded to be case sensitive, this wasn't a problem with IE7 but now causes most pages to crash on chrome and others.
I am going page by page finding id's and doing updates to all codes to match same casing. But this is taking a lot of time and lots of checking on each page.
I did a little search for a simpler way to fix these but could not find any solution. Is there a way to do this to all the files 100+ pages 1000's of lines of code.
We are using studio 2012 pro. We are open for any other tool that can solve the issue.
Thank you for the help.