3

I have old code from 2011 that has always worked properly. That is until Chrome 39. After beating my head in for awhile to try to diagnose, I determined that it works fine in IE, Firefox, and Chrome <= version 38. As of Chrome version 39, just a blank page is shown.

Seems like there is a change in handling of xsl/xslt, or xml, that is not allowing the page to render properly.

Are there any known changes to Chrome that would cause this? Any fix or workaround?

Thanks!

Example:

http://redemption.armory DOT eternal-wow.com SLASH arena-ladder.xml?ts=2&b=Eternal-WoW%21 http://eternal-wow.com

Derek
  • 45
  • 6
  • Your first link is a 404 error - also you should post code snippets here to help others assist you rather than just relying on links. See this guide: http://stackoverflow.com/help/how-to-ask – Stewart_R Nov 22 '14 at 22:48
  • It's not a 404. Works fine. There's too much code to paste since I've have no idea where the issue lies. – Derek Nov 22 '14 at 22:53
  • Nope - not for me, it 302's to http://redemption.armory.eternal-wow.com/login.xml?ref=character-select.xml which is a 404 error – Stewart_R Nov 22 '14 at 22:57
  • Behviour same as i descibe when tesing with: http://web-sniffer.net/ – Stewart_R Nov 22 '14 at 22:58
  • You're just getting confused by the login redirect. I removed the first link so you don't keep trying that. Use the remaining link that doesn't require a login. – Derek Nov 22 '14 at 23:14
  • That 404 is not part of the problem you're describing. a 404 error is not browser specific – Stewart_R Nov 22 '14 at 23:16
  • Read above. Also there is no 404. Connect to 141.101.123.10 on port 80 ... ok GET /arena-ladder.xml?ts=2&b=Eternal-WoW%21 HTTP/1.1 Host: redemption.armory.eternal-wow.com Connection: close User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Accept-Encoding: gzip[CRLF] Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7 Cache-Control: no-cache Accept-Language: de,en;q=0.7,en-us;q=0.3 Referer: http://web-sniffer.net/ HTTP R Status: HTTP/1.1 200 OK – Derek Nov 22 '14 at 23:18
  • There was a 404 on the link you just removed from your original post by editing it before making the claim it doesnt exist... – Stewart_R Nov 22 '14 at 23:21
  • There was a 302 redirect on the first link, exactly like you said earlier before you changed your story. Do you wish to actually help now? – Derek Nov 22 '14 at 23:35
  • the 302 was a redirect to a 404... – Stewart_R Nov 22 '14 at 23:38
  • Believe it or not I really am TRYING to help you (or at least trying to assist you find the help you need). Your first post popped up out of the review q. I tried to add comments that I thought would help you find the assistance you needed. – Stewart_R Nov 22 '14 at 23:41

1 Answers1

2

The link works in Firefox but results in blank page in Chrome. I checked with webdev tools and noticed that Chrome loads the xsl files from a different url as Firefox, e.g. .._layout/arena/language.xsl (404) instead of ../_layout/language.xsl (ok). In addition in Chrome I get the error message "Resource interpreted as Stylesheet but transferred with MIME type application/xslt+xml: "http://redemption.armory.eternal-wow.com/_layout/arena/ladder.xsl".
For this issue check Chrome says: Resource interpreted as Stylesheet but transferred with MIME type application/xml

The main problem seems to be the misinterpred xsl:import and xsl:include statements which seems to be a Chrome/Webkit Bug - see e.g. https://code.google.com/p/chromium/issues/detail?id=8441 or google for "xsl import relative path chrome". The first import in ladder.xsl works: <xsl:import href="../includes.xsl" /> (is loaded from ../_layout/includes.xsl). The <xsl:import href="language.xsl"/> in the includes.xsl fails in Chrome - it's resolved to ../_layout/arena/language.xsl instead of ../_layout/language.xsl. Same applies to the xsl:includes, e.g. in the language.xsl - . <xsl:include href="nav/menu.xsl" /> tries to include from ../_layout/arena/nav/menu.xsl instead of ../_layout/nav/menu.xsl.
As it seems to be a Chrome Bug, you could either try to just copy the xsl files to the location where Chrome is looking for them or try to adjust the include/import paths as Chrome seems to interpret the locations based on the main template - as "../includes.xsl" is working as import from the ladder.xsl in the arena-directory but <xsl:import href="language.xsl"/> in the includes.xsl is not resolved relative to the language.xsl, but instead relative to the ladder.xsl, changing to <xsl:import href="../language.xsl"/> might work for Chrome (but maybe won't work for other browsers, so I won't recommend that). Two suggestions - either you double the imports/includes, keeping the current imports/includes and adding each of them with a path relative to the ladder.xsl, or, which would be a cleaner solution, you check if you can move all imports and includes to the ladder.xsl and adjust the paths accordingly.

Community
  • 1
  • 1
matthias_h
  • 11,356
  • 9
  • 22
  • 40
  • You're absolutely right. I at first tried symlinks to fix the issue, but that didn't work. So I changed all the included files to absolute paths instead of relative paths, and that fixes the issue. It's kind of a dirty fix, and it will require hundreds of changes to affect the whole site. I'm sure there's a better approach, maybe using .htaccess or something, but I'm not sure what. – Derek Nov 23 '14 at 01:16
  • Nevermind, it kind of breaks it for the other browsers. That doesn't work at all. – Derek Nov 23 '14 at 01:20
  • I tried the symlink thing again, and had missed some before. It actually works if I get every link. It's just very messy and drives me crazy. – Derek Nov 23 '14 at 01:36
  • @Derek Though it's also a kind of a dirty fix - just keeping the xsls at the current location where it's working for non-webkit browers and copying them to the location where Chrome is trying to load is not an option? Just cause that shouldn't require so many changes. But if the symlink approach works it's of course the better solution as it's cleaner. – matthias_h Nov 23 '14 at 01:38
  • Thanks for your help. I'm going to go with this symlink method for now. It's much better than duplicate files. I've marked yours as the answer, but if anyone knows a better way or a fix, please let me know. – Derek Nov 23 '14 at 01:47