From: Mikko R. <mik...@pe...> - 2012-08-28 09:12:29
Attachments:
signature.asc
|
Am I the only one suffering from the issue that Google Chrome tries to load file "JmolApplet.class" from server when Jmol-JSO library is used. Example: http://biomodel.uah.es/Jmol/JSO/simpleJmol3-0.htm To view the issue, open the URL above in Google Chrome (I tested 22.0.1229.14 beta and 23.0.1246.0 canary), press F12 and select Network. Reload the page and grant permission to run Java applet. Notice that Jmol-JSO library causes extra request for JmolApplet.class for each Jmol view. The above example seems to use Jmol 12.3.23 but I'm reproducing the same issue with Jmol 13.0.1. The issue is probably caused by the logic in Jmol._Applet._createApplet definition in JmolApplet.js on line 98: 96: params.mayscript = 'true'; 97: params.codebase = applet._jarPath; 98: params.code = myClass + ".class"; The 'params.code' causes Chrome to blindly trying to load the JmolApplet.class from the codebase path. I don't know a proper fix for the issue. Both the example above and my internal test case are using HTML5 doctype so perhaps the problem is related to that. It seems that the above code is supposed to only run in case of HTML 4.0 document or if the user agent is some variant of Internet Explorer because it guarded by a following test: if (Jmol.featureDetection.useIEObject || Jmol.featureDetection.useHtml4Object) (As a related note, has anybody successfully used Jmol in XHTML5 document? I tried to do so but never got it to work.) -- Mikko |
From: A. H. <ang...@ua...> - 2012-08-28 10:55:04
|
> Example: http://biomodel.uah.es/Jmol/JSO/simpleJmol3-0.htm That's my page. Be careful, since I am not sure what set of files that is using (I cannot update the site now from where I am). I think that 3-0 page was using the standard JS files included in Jmol distribution, but maybe I changed them with some of Bob's fixes along my prevous discussion. Be sure to test also with Jmol 13.0 as you are doing. > To view the issue, open the URL above in Google Chrome (I tested > 22.0.1229.14 beta and 23.0.1246.0 canary), press F12 and select Network. > Reload the page and grant permission to run Java applet. Notice that > Jmol-JSO library causes extra request for JmolApplet.class for each Jmol > view. So is this a Chrome-only issue? > The 'params.code' causes Chrome to blindly trying to load the > JmolApplet.class from the codebase path. I think that the setting of params.codebase and params.code has always been like that, and that's how the applet is expected to be initiated. What happens if you try using Jmol.js intsead of JSO? Maybe it's restricted to HTML5 as you say, I've only started to use this doctype recently. > if the user agent is some variant of Internet Explorer because it > guarded by a following test: > > if (Jmol.featureDetection.useIEObject > || Jmol.featureDetection.useHtml4Object) Shouldn't be that. Chrome will fall into the "useHtml4Object" filter. No worries about IE-specific code. |
From: Mikko R. <mik...@pe...> - 2012-08-28 11:41:41
Attachments:
signature.asc
|
2012-08-28 14:06 Europe/Helsinki: Angel Herráez: >> Example: http://biomodel.uah.es/Jmol/JSO/simpleJmol3-0.htm > > That's my page. Be careful, since I am not sure what set of files that is using > (I cannot update the site now from where I am). I think that 3-0 page was > using the standard JS files included in Jmol distribution, but maybe I > changed them with some of Bob's fixes along my prevous discussion. Be > sure to test also with Jmol 13.0 as you are doing. OK. I was pointing to that page as an example about somebody else using Jmol-JSO and hitting the same issue with Google Chrome. I didn't know it was you. >> To view the issue, open the URL above in Google Chrome (I tested >> 22.0.1229.14 beta and 23.0.1246.0 canary), press F12 and select Network. >> Reload the page and grant permission to run Java applet. Notice that >> Jmol-JSO library causes extra request for JmolApplet.class for each Jmol >> view. > > So is this a Chrome-only issue? At least I have only seen it with Google Chrome. >> The 'params.code' causes Chrome to blindly trying to load the >> JmolApplet.class from the codebase path. > > I think that the setting of params.codebase and params.code has always > been like that, and that's how the applet is expected to be initiated. What > happens if you try using Jmol.js intsead of JSO? I haven't tested that because I'm (at least currently) using features provided only by JSO version. > Maybe it's restricted to HTML5 as you say, I've only started to use this > doctype recently. It seems that (at least with HTML5 doctype) chrome applies following logic if all following "params" are set: - archive - codebase - code Then proceed trying to load URI codebase+code and if that fails, try to load codebase+archive and then initiate class pointed by code within the archive. I have no idea how to start the code without Chrome trying to load the codebase+code URI first. >> if the user agent is some variant of Internet Explorer because it >> guarded by a following test: >> >> if (Jmol.featureDetection.useIEObject >> || Jmol.featureDetection.useHtml4Object) > > Shouldn't be that. Chrome will fall into the "useHtml4Object" filter. No worries > about IE-specific code. OK. The variable naming misguided me a bit. -- Mikko |
From: A. H. <ang...@ua...> - 2012-08-28 18:18:57
|
This same issue seems to be reported as a Chromium bug, http://code.google.com/p/chromium/issues/detail?id=115880 http://code.google.com/p/chromium/issues/detail?id=71525 but no solution is offered and it has been closed as "obsolete" ?? |
From: A. H. <ang...@ua...> - 2012-08-28 17:21:10
|
Well, I've looked into this a little and I see the error same as Mikko, only in Chrome. The error is there in both Jmol.js and JSO methods, but other browsers seem not to notice or care about this. And it happens the same with either doctype, HTML5 or HTML4 (4.01 Transitional) But the interesting thing --for me-- is comparison of Jmol.js and JSO output: Jmol.js creates the OBJECT with <param name="code" value="JmolApplet"> while JSO puts: <param name="code" value="JmolApplet.class"> So here is something to look at. Indeed, JmolApplet.js source has params.code = myClass + ".class"; which is called with a "JmolApplet" parameter while Jmol.js has params.code = 'JmolApplet'; The applet loads successfully in all cases. |
From: Robert H. <ha...@st...> - 2012-08-28 19:26:29
|
I think it's just a nuisance, not a problem. see below On Tue, Aug 28, 2012 at 4:12 AM, Mikko Rantalainen < mik...@pe...> wrote: > Am I the only one suffering from the issue that Google Chrome tries to > load file "JmolApplet.class" from server when Jmol-JSO library is used. > > Example: http://biomodel.uah.es/Jmol/JSO/simpleJmol3-0.htm > > However -- Angel -- is that page supposed to load, or was that a demo of the problem we were having? I note that it does not load correctly in FireFox. > To view the issue, open the URL above in Google Chrome (I tested > 22.0.1229.14 beta and 23.0.1246.0 canary), press F12 and select Network. > Reload the page and grant permission to run Java applet. Notice that > Jmol-JSO library causes extra request for JmolApplet.class for each Jmol > view. > > The above example seems to use Jmol 12.3.23 but I'm reproducing the same > issue with Jmol 13.0.1. > > The issue is probably caused by the logic in Jmol._Applet._createApplet > definition in JmolApplet.js on line 98: > > 96: params.mayscript = 'true'; > 97: params.codebase = applet._jarPath; > 98: params.code = myClass + ".class"; > > The 'params.code' causes Chrome to blindly trying to load the > JmolApplet.class from the codebase path. I don't know a proper fix for > the issue. Both the example above and my internal test case are using > HTML5 doctype so perhaps the problem is related to that. It seems that > the above code is supposed to only run in case of HTML 4.0 document or > if the user agent is some variant of Internet Explorer because it > guarded by a following test: > > if (Jmol.featureDetection.useIEObject > || Jmol.featureDetection.useHtml4Object) > > useHtml4Object is true for any system at least as advanced as Html4. > (As a related note, has anybody successfully used Jmol in XHTML5 > document? I tried to do so but never got it to work.) > > How does one distinguish by DOCTYPE XHTML5 and HTML5? > -- > Mikko > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: A. H. <ang...@ua...> - 2012-08-29 11:14:41
|
> Example: http://biomodel.uah.es/Jmol/JSO/simpleJmol3-0.htm > > However -- Angel -- is that page supposed to load, or was that a demo of the problem we were > having? I note that it does not load correctly in FireFox. It was for demonstrating the problem with percent-sized applets, at least in the JSO set included in RC5. For me only the Jmol on the right is displayed (that one is in pxels). The other two applets load but with size zero, I think. The problem should be fixed in later versions --but I cannot play with those files in the server now. Just forget that page as a trustable reference. I will try to set proper, up-to-date, demos when I am back at the uni with full access. > 96: params.mayscript = 'true'; > 97: params.codebase = applet._jarPath; > 98: params.code = myClass + ".class"; I think that + ".class" part should be removed from JmolApplet.js --not that it makes a difference for the browsers, apparently, but the proper syntax for 'code' seems to be the file name without the extension. Or if otherwise, it should be matched (and hence changed) in Jmol.js --which has always used "JmolApplet" without the .class-- |
From: Mikko R. <mik...@pe...> - 2012-08-29 12:02:54
Attachments:
signature.asc
|
2012-08-28 22:26 Europe/Helsinki: Robert Hanson: >> (As a related note, has anybody successfully used Jmol in XHTML5 >> document? I tried to do so but never got it to work.) >> > How does one distinguish by DOCTYPE XHTML5 and HTML5? HTML5 is a resource with Content-Type: text/html where the start of the file reads (case insensitive) "<!DOCTYPE html>". XHTML5 is a resource with Content-Type: application/xhtml+xml where the start of the file may start with (case insensitive) "<!DOCTYPE html>". Note that technically DOCTYPE declaration is not required for XML (or XHTML5) files. The latter is a real XML file as opposed to HTML5 variant that should use HTML5 parser if available. -- Mikko |
From: Robert H. <ha...@st...> - 2012-08-29 12:33:17
|
I guess I don't have a server that will deliver up Content-Type: application/xhtml+xml, so I haven't been able to test that. Is there a way to coerce that for a browser? Do you have an example page that does that? On Wed, Aug 29, 2012 at 7:02 AM, Mikko Rantalainen < mik...@pe...> wrote: > 2012-08-28 22:26 Europe/Helsinki: Robert Hanson: > >> (As a related note, has anybody successfully used Jmol in XHTML5 > >> document? I tried to do so but never got it to work.) > >> > > How does one distinguish by DOCTYPE XHTML5 and HTML5? > > HTML5 is a resource with Content-Type: text/html where the start of the > file reads (case insensitive) "<!DOCTYPE html>". > > XHTML5 is a resource with Content-Type: application/xhtml+xml where the > start of the file may start with (case insensitive) "<!DOCTYPE html>". > Note that technically DOCTYPE declaration is not required for XML (or > XHTML5) files. > > The latter is a real XML file as opposed to HTML5 variant that should > use HTML5 parser if available. > > -- > Mikko > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Mikko R. <mik...@pe...> - 2012-08-30 08:04:56
Attachments:
signature.asc
|
2012-08-29 15:33 Europe/Helsinki: Robert Hanson: > I guess I don't have a server that will deliver up Content-Type: > application/xhtml+xml, so I haven't been able to test that. Is there a way > to coerce that for a browser? Do you have an example page that does that? The only way to do that over HTTP is to get the server to emit content-type application/xhtml+xml. You can get the browser to consider a local file as application/xhtml+xml if you call it e.g. "index.xhtml". Technically it should be okay to call it "index.xml" but in that case the content type is application/xml which *should* work but in real world probably does not. I don't have a public web page that contains jmol and is served as application/xhtml+xml. Note that real XHTML5/XML files must declare the namespace for the <html> element, like this: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fi" lang="fi" dir="ltr"> The "xml:lang" and "lang" and "dir" are all optional. Officially, "xml:lang" will declare the content language for any XML document but that does not work correctly in Firefox 14 or lesser (automatic hyphenation of body text requires supported language). Officially the <html> element does not have "lang" attribute in XHTML mode but Firefox uses only that attribute to figure out the content language. Of course, if your content language is not Finnish (left to right), then you want to say something else for the lang and dir attributes. PS. to get automatic hyphenation to work, you'll need extra CSS like this: body { -webkit-hyphens: auto; /* http://crbug.com/47083 */ -moz-hyphens: auto; /* Firefox 8.0+ */ -ms-hyphens: auto; /* MSIE 10.0+ */ hyphens: auto; /* future browers */ } /* Webkit (iOS safari and friends) fixes (http://code.google.com/p/hyphenator/wiki/en_CSS3Hyphenation) */ [lang='en'] { -webkit-locale: 'en'; } [lang='fi'] { -webkit-locale: 'fi'; } [lang='sv'] { -webkit-locale: 'sv'; } /* Check for UA auto hyphenation support at http://hyphenator.googlecode.com/svn/dictChecker.html */ -- Mikko |