Getting reports from visitors that they are seeing a sad face load instead of the maps. Using the latest API.
Has anybody ever seen this or know the reason why it would show up?
We can be sure that our JS API 3.x works properly in all modern browsers and operation systems.
You can't reproduce the issue because it seems your visitors have some own issues on their side related to network, operation system, version of browsers, 32-bit browser installed on 64-bit OS, blocked map content by installed browser's extensions and etc. and etc. Because is not possible to list all potential issues would be better that visitors search the issue on his side e.g. search in internet "browsers can't load websites" or "my browser crashing"
Related
Chrome is on the verge of definitly break compatability with NPAPI, and IE breaking with ActiveX the future of Java Applets is dark. Currenty we actively use a secure applet for out client organizations that enables their users to upload a bunch of files from their file system to our servers with the click of a button. The applet has full access to any configured drive, including network drives.
With the imminent death of the applet this functionality is going to be lost if we don't find an alternative. I have already tried to explore different solutions, including the chrome FileSystem API but that is currently only available for Chrome (http://caniuse.com/#feat=filesystem) and has limited access.
Does anybody know about an alternative to keep supporting the much appreciated functionality? Unfortunately we are obligated to support all browser down to IE8.
I've written a post about this here.
Once Google Chrome was the first to announce that they won’t be supporting NPAPI anymore, they were also the first to provide a new architecture in order to rewrite your code to work on their browser. You can take a look on Native Messaging, which “can exchange messages with native applications using an API that is similar to the other message passing APIs”. The problem is that this approach only works on Chrome, is not something that you can adapt to other browsers.
A more useful approach is FireBreath, a browser plugin in a post NPAPI world. Check the words below from one buddy of the project:
“FireBreath 2 will allow you to write a plugin that works in NPAPI, ActiveX, or through Native Messaging; it’s getting close to ready to go into beta. It doesn’t have any kind of real drawing support, but would work for what you describe. The install process is a bit of a pain, but it works. The FireWyrm protocol that the native messaging component uses could be used with any connection that allows passing text data; it should be possible to make it work with js-ctypes on firefox or plausibly WEB-RTC or even CORS AJAX in some way. For now the only thing we needed to solve was Chrome, but we did it in a way that should be pretty portable to other technologies.”
In light of the answer provided by Uly Marins I have researched the options suggested. Unfortunately these options weren't viable for our application, because the mayority of our users do not have sufficient rights to install third party plugins. Additionally the API is still in Beta which won't do any good in a stable production environment.
The main problem we wanted to solve was the abbility to delete files from the accessed folders. It seemed like one of the mayor goals of the removal of the NPAPI support was exactly to prevent this kind of possibility. Therefore we needed to reduce our goals to a simple solution that was still acceptable for our users, with the additional training on how to clear the selected folder manually (because most of our users are almost computer illiterate and needed to access network folders).
Long answer short. The requested solution is just not possible anymore and had to be replaced by a simpler solution and additional training.
We are using webspeech(https://www.drupal.org/project/webspeech) module for text-to-speech in one of our project. Basic functionality is working fine. But when we open this site in mobile devices (samsung, apple, sony) TTS feature is not working and no error is also being displayed.
We have tried to debug the problem but not able to do so.
Any help will be much appreciate.
If you read the module requirements it says specifically
Flash 9+ is required on client web browser. Modern browsers those
support HTML5 may also work but not guaranteed.
I see you opened an issue with the maintainer, which will probably be your best source of information, but it looks like you might be hit or (mostly) miss on mobile devices for now.
Sometimes, (more often than not), the browser screen freezes while navigating through a Meteor app. Basically everything works fine but I cannot scroll up or down.
There are no JS errors and everything seems to be running ok.
What could be causing htis?
This is often a hard thing to debug, but the first things I'd do are :
Disable your CSS (sometimes the silliest things can seem disasterous)
Check that there are no errors, in your terminal either (Meteor logs to the browser and terminal)
could you be flooding the front end with data? how big are your collections? are you using auto-publish or neatly crafted pub/subs?
What packages have you included in your project? try disabling any non essential packages
Install Kadira, and monitor your performance
Its really hard without more information, off the top of my head I imagine that you're either experiencing some weird styling / rendering issue, or that you're waiting on oversized subscriptions. Meteor overall should feel quite fluid and quick. I have a few questions :
Can you share more information about your app or where you're experiencing the issues you've described?
Is your project available anywhere?
What Browser are you viewing it in?
localhost or on a server? (if so what server environment?)
So recently Microsoft threw the joke that was IE6 into the recycling bin, and said that users should automatically be upgraded to the latest version of IE, if they hadn't already. Unfortunately for web designers, this means that some people (running XP) will be stuck with IE8.
I recently started redesigning a clients website to bring it up to date, and in order to make loading times quicker, save on disk usage, and on bandwidth, I have implemented the use of CSS3 code and then a big but... IE8 Doesn't support CSS3... :(
Is there a significant amount of users on XP / Vista / 7 who still use IE8, or have they moved to alternative, more up to date browsers such as Chrome, Firefox, Safari etc?
Should I worry about trying to find a way to keep the website looking correct in all browsers? or is there a way for me to encourage visitors using IE8, to swap it for another browser?
I imagine this depends on how the website is used. Is it an intranet website, a public website, or an web application that the owner dictates the version. IMO the best way to figure this out is to have Google Analytics plugged into the web app.
I can tell you that the project I am currently on doesnt have the luxuary to rule out IE8. 70% of our users that use the web app I work on use IE8. It seems to still be the most used browser in the business world. (at least from my experience) Heck we still need to support IE7.
However if you can guarantee the web users are using an up to date browser, then thats a different story. Or of course you can say, this app doesnt support IE 8 or lower.
Thats my 2 cents.
IE8 is the default browser in Windows 7, so expect it to hang around forever, just as IE6 has because it was the default in Windows XP.
Use http://code.google.com/p/html5shiv/ or http://code.google.com/p/ie7-js/ to ease the pain.
Yes, but according to WC3 the percentage of usage is now only ~8% for IE8.
Thats still a pretty big number to turn your back on however.
What's the best way for determining whether the user's browser can view PDF files?
Ideally, it shouldn't matter on the browser or the operating system.
Is there a specific way of doing it in ASP.NET, or would the answer be just JavaScript?
Neither, none, don't try.
Re dawnerd: Plug-in detection is not the right answer. I do not have a PDF plugin installed in my browser (Firefox on Ubuntu), yet I am able to view PDF files using the operating system's document viewer (which is not Acrobat Reader).
Today, any operating system that can run a web browser can view PDF files out of the box.
If a specific system does not have a PDF viewer installed and the browser configured to use it, that likely means that either it's a hand-made install of Windows, a very trimmed down alternate operating system, or something really retro.
It is reasonable to assume that in any of those situation the user will know what a PDF file is and either deliberately choose not to be able to view them or know how to install the required software.
If I am deluding myself, I would love to have it explained to me in which way I am wrong.
A quick google search found this. Useful for all kinds of plugins.
There are users that choose not to open PDF's in the browser and disable the plugin (this allows the file to be opened in the native application external of the browser window). It is better to let the user know that software is required to open something (whether it be PDF or not) than try to detect whether the plugin is available.
Another problem with detection is that what you need to look for changes from version to version (for example, see: "PDF.PdfCtrl.*" vs "AcroPDF.PDF.*" for the Adobe PDF viewer) and different browser implementations (the previously mentioned strings are used in IE for example, while Firefox uses a totally different manner of detection. Then we need to think of Opera and Safari and ???). Also, there are different vendors (think Foxit and Ghostscript, though I am not sure if they supply a plugin for the browser) where there may be differences in detecting the plugin.
For a script written in 2008 and some more information about the caveats see Detecting plugins in Internet Explorer (and a few hints for all the others).
After initially ignoring the advise on this page the architect went ahead with Acrobat detection, causing an inevitable support nightmare.
As ddaa mentions not all the scenarios can be accurately captured with Plug-in detection. Some users, for example, may choose to view PDF files with FoxIt Reader rather than acrobat. Some user's browsers don't flag that they are Acrobat ready, and certainly not always in the same way.
A better solution would have been to give the user a choice on how they'd like to view the relevant document. Personally, I don't like to have any website rely on a plug-in - it spoils the beauty of the web.