So last week, one of our applications started to display a weird bug: the € signs got displayed as € signs. After some digging around, I noticed that it happened to every price amount we display that went through a formatting function. So checking the source code in devtools revealed why we were seeing a different character:
return "€ " + x1 + ",-"
So, it looks like the script got served with a different encoding than UTF-8. The source code clearly shows a euro sign on that line, but the source tab in Chrome devtools says different.
I tested it out in multiple browsers where Firefox, IE 11 and Edge correctly showed a euro sign. Opera didn't, so that looks like it's a Webkit issue?
If I full-refresh the page in Chrome (ctrl+shift+R), everything looks okay and all euro signs are rendered correctly.
This question states that the € character is displayed because ISO-8859-1 is used for rendering (which doesn't have the euro sign). Is it possible for Webkit to just pick a different encoding to parse JavaScript files with than UTF-8?
Giacomo Catenazzi's comment above pointed me into the right direction. The application is hosted on a Java back-end, and as such has a login.html and app.html page that the Java back-end serves as index. I knew that app.html has a <meta charset="utf-8"> tag in the <head>, but the comment inspired me to check login.html and I noticed that it missed the meta tag.
login.html loads the application script file. So when the user logs in, Chrome fetches the script file on the login page with no specific encoding, and when the user moves on to the application page, the (improper encoded) script file is served from cache. This explains why a refresh fixed everything (scripts get refetched from server), and it also explains why this happened "suddenly". The login page was changed recently to load the scripts file.
TLDR; make sure every HTML file that fetches scripts has a <meta charset="utf-8"> in its <head>.
Related
I've been having this problem for some days now and spend 2 hours debugging a simple meta tag without result.
The problem I'm facing is that the facebook debugger provides me with a whole different url from cloudfront and sets wrong meta image.
The url
The Image it should show
I also made a thread on facebook.com: https://developers.facebook.com/bugs/807177749469671/
The object debugger from Facebook for your given URL mentions that some redirects are occurring on the page, it's also mentioning when these redirections occur. It can either be an HTTP direction, meta-tag with og:url property or a link tag. Your page does contain one of these tags, on line 91 to be specific;
<link rel="dns-prefetch" href="//yummygum.com">
This redirection is why Facebook is trying to load an image with the name "meta-img.png" since this is the og:image the homepage is referring to. Try to remove that link redirection and see if it's loading the right image.
I have tried to set my site up ( http://www.diablo3values.com )according to the guidelines set out here : https://developers.google.com/webmasters/ajax-crawling/ However, it appears that Google has updated their indexes (because I see the revisions to the meta description tags) but the ajax content does not show up in the index.
I am trying to use the “Handle pages without hash fragments” option.
If you view either of the following:
http://www.diablo3values.com/?_escaped_fragment_=
http://www.diablo3values.com/about?_escaped_fragment_=
you will correctly see the HTML snap shot with my content. (those are the two pages I an most concerned about).
Any Ideas? Am I doing something wrong? How do you get google to correclty recognize the tag.
I'm typing this as an answer, since it got a little to long to be a comment.
First of all, your links seems to point to localhost:8080/about, and not /about, which probably is why google doesn't index it in the first place.
Second, here's my experience with pushstate urls and Google AJAX crawling:
My experience is that ajax crawling with pushstate urls is handled a little differently by google than with hashbang urls. Since google won't know that your url is a pushstate url (since it looks just like a regular url), you need to add <meta name="fragment" content="!"> to all your pages, not only the "root" page. And google doesn't seem to know that the pages are part of the same application, so it treats every page as a separate Ajax application. So the Google bot will never actually create a navigation structure inside _escaped_fragment_, like _escaped_fragment_=/about, as it would with a hashbang url (#!/about). Instead, it will request /about?_escaped_fragment_= (which you aparently already have set up). This goes for all your "deep links". Instead of /?_escaped_fragment_=/thelink, google will always request /thelink?_escaped_fragment_=.
But as said initially, the reason it doesn't work for you is probably because you have localhost:8080 urls in your _escaped_fragment_ generated html.
Googlebot only knows to crawl the escaped fragment if your urls conform to the hash bang standard. As users navigate your site, your urls need to be:
http://www.diablo3values.com/
http://www.diablo3values.com/#!contact
http://www.diablo3values.com/#!about
Googlebot actually needs to see these urls in the source code so that it can follow them. Then it knows to download the following urls:
http://www.diablo3values.com/?_escaped_fragment=contact
http://www.diablo3values.com/?_escaped_fragment=about
On your site you appear to be loading a new page on each click, and then loading the content of each page via AJAX too. This is not how I would expect an AJAX site to work. Usually the purpose of using AJAX is so that the user never has to load a whole new page. When the user clicks, the new content section is loaded and inserted into the page. You serve the navigation once and then you only serve escaped fragments of the content.
We use CentOS-6, a RedHat EL6 distro rebuild, and this ships with FireFox-10.0.12 ESR. We recently changed the favicon.ico image on several internal servers. Actually we just provided the corporate favicon to those sites that had none.
Now, the difficulty is this. When a FF user who visited a given url before the favicon was provided now visits that url following the update then the new favicon is not displayed in either their URL address bar or in the tab for that page. Instead they see that dashed box outline indicating that no favicon is present.
However, when a FF user who had never previously visited that same url does so then that FF instance does display the new favicon in both the address bar and tab on that FF browser.
I have looked into this briefly and frankly was astounded at how common this problem appears to be and the absolute lack of any sensible response to the issue even on Mozilla's own support forums. I have tried hacking and picking at the places.sqlite store but even deleting the entire places.sqlite file or emptying the favicon tables and restarting firefox does not solve the problem of displaying a changed favicon the tab and url icon display. All that does is hammer the user's bookmarks.
Now I can, and have, resorted to the trick of adding <link rel="icon" href="favicon.ico"> in the <head></head> block of those urls that use static pages but some are generated dynamically by third-party applications. These urls do not offer a convenient method to make this modification to their output.
Where does FireFox-10 cache the favicon for a newly visited url and how does one remove that reference from the user's profile?
A browser does not necessarily request a fresh copy of the /favicon.ico (or an icon specified by a meta tag) on each visit. Once it has a favicon (or thinks there isn't one), it is often some time before it will request an update (this depends on the particular browser). I have had some success with unbookmarking a site and clearing the browser cache.
I'm under the impression that the user agent stylesheet in browsers such as Safari, Chrome and Firefox is something that is internal to the browser and can't be directly modified (rather a style property needs to be overridden).
I'm also under the impression due to various websites including Mozilla's that the default value of the box-sizing property for Webkit and Mozilla is "content-box."
I tested this on a rather simple dummy page viewed in various browsers.
My problem is that on two pages in our production application the default property is different, and we can't figure out why this is.
One one page we see a box-sizing property of "border-box" in the Web Inspector or console. It's assigned to the CSS selector input:not([type="image"]), textarea.
On the other page there is no mention of the box-sizing property in the Web Inspector or console.
Does anyone know if there's some way to directly affect the box-sizing definition in the user agent stylesheet for a particular page? Maybe there's a library that does this? We're using prototype.js and swfobject.js in the application...
UPDATE: In case I wasn't clear on almost every page in my web application and in every "dummy" page I've tested on the box-sizing property has the default "content-box" value. For some reason one particular page in my web application shows in the web inspector that the user agent stylesheet (the one used by the browser for its defaults) has set that property to "border-box." I can't for the life of me figure out why this is. I'm looking for anything that might cause Firefox to change what its default value for that property is.
Just had this same issue. What was happening in my case was that someone had put a snippet of Javascript code above the <!doctype html>. As a result, when I inspected DOM through firebug, it appeared that the document didn't have a doctype.
When I removed the snippet of JS code such that the doctype declaration was at the very top of the file, the doctype reappeared and fixed the box-sizing problems I was seeing (the same one you had).
See:
Hope this helps.
I had the same issue on chrome which by default added the following user agent style rule:
input:not([type="image"]), textarea {
box-sizing: border-box;
}
After adding the doctype property <!DOCTYPE html> the rule no longer appeared.
No, you can't touch the browser default stylesheet, and yes, browsers do have different rules for box-sizing specifically in respect to form fields. This is for compatibility with old browsers that used to implement form fields entirely with native OS widgets that CSS couldn't style (and so which didn't have ‘border’ or ‘padding’ as such).
Why not just put your box-sizing/-moz-box-sizing/-webkit-box-sizing rule in the site stylesheet? Works for me, I often use this to make inputs with set widths line up across modern browsers. (IE 6–7 don't support it, though, so need some extra help.)
I am developing web-application using Google Maps API and ASP.NET Ajax. Here is my JavaScript-code for PageLoad:
map.openInfoWindowHtml(map.getCenter(),'Hello, <b>world</b>!');
First run is successful. But after execution some ASP.NET Ajax-function we have strange effect: In Internet Explorer, Mozilla Firefox and Opera everything is good, but in Google Chrome and Safari text with html-tags is invisible. In other words in Google Chrome we have text: “Hello, !”
I want to make the application that would normally in Google Chrome and Safari too. How can I do it?
Update:
String "Hello, <b>world</b>, <strong>world</strong>, <span style='font-weight: bold;'>World</span>, <a href='http://ya.ru'>Link</a>." transform to "Hello, , , , . " (I examined the DOM). Words really are disappearing.
I observed this strange effect on any Ajax-function with request to server.
Update2:
Many thanks to Koobz for many leading questions. They helped me a more detailed understanding of the problem.
First of all, full description of actions:
Load the page. GMap have several markers with dblclick-event in JavaScript. Dblclick event exec marker.openInfoWindowHtml(/My text/). /My text/ is located in JavaScript of my Page.
I double-click on the marker. I see a infoWindow with a normal formatting
Exec __doPostBack (starndard ASP.NET PostBack)
In server side JavaScript is updated with same
Server return some information with /My text/ to my page
I doouble-click on the marker. I see a infoWindow with a wrong formatting.
An interesting fact, which puts me in embarrassing:
I try set to “Hello, <b>world</b>, <b>test</b>”
Before Ajax function in all browser I have: “Hello, world, <b>test</b>”
After Ajax function in Google Chrome and Safari: "Hello, ,test"
After Ajax function in Mozilla, Opera and IE: “Hello, world, <b>test</b>”
What Chrome and Safari have features that may cause such behavior? Now I can write separately necessary infoWindow-text for each browser. But I would like to find a normal way to solve my problem.
Hit ctrl+shift+j to open up your chrome developer tools.
Set a breakpoint right before the function call that breaks everything.
Attempt to reproduce the bug.
After the break point hits, step through your code until the text disappears.
Set a breakpoint after the text first disappeared.
Repeat this process. Refine your breakpoints until you've narrowed down where the bug is occurring.
It could be any number of things. I have no idea what kind of Ajax things you're doing. Are you dynamically updating content on your page after doing the request? It's possible that this update code is modifying dom elements that it shouldn't be. Tracing through using the methodology above will help nail it if this is the case.
If you're using jQuery, maybe one of your selectors is out of whack and it's eating up content. Chrome is very good and I'm hesitant to believe it's a javascript bug or anything like that.
Validate your HTML. If you're traversing the dom, invalid markup might result in chrome "seeing" a different picture than other browsers. Just look for broken tags and ignore all the other things a validator complains about.
Wild guess: but the way it's stripping out HTML might point to some kind of XSS protection. Is the Ajax script that's returning the new HTML code on another domain than the one the visitor is viewing?
Some info here:
http://groups.google.com/group/chromium-dev/browse_thread/thread/d2931d7b670a1722/d56bdfccfcef677f
Do you see the problem with any html tags in the info window? As an experiment, try:
<span style="font-weight: bold;">World</span>.
I am wondering if there is a unclosed bold tag somewhere in the DOM?
I am messing around with this problem, but I haven't been able to reproduce it. Having a look at what the Ajax function does would be helpful.
Try this:
map.openInfoWindowHtml(map.getCenter(),'Hello, <strong>world</strong>!');
the strong tag is more standards compliant, worth a shot
As others have said, you need to post your code.