Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On 12.11.2010 09:29, Julian Reschke wrote: ... Surely, there is no way (that I'm aware of) to guarantee correct downloaded file name in all browsers for all users. A lot of server operators only care about users in their country, and can reasonably (i.e. with negligible cost to business) rely on Windows locale being set. They can just send raw bytes in language default encoding in Content-Disposition, and that works for them and their clients. For all I know, that's what almost everyone does, and it's interoperable for them. Yes. That was the case back in 2003 when I only had to worry about IE and Mozilla/Firefox, and it hasn't been improving until 2008 when I started the work on collection test cases *and* results, and started updating the specs. Since then some of the implementations of 2231 encoding (now 5987) have improved a bit (Opera) / a lot (Konqueror), FF has a few pending patches, and Chrome nighties have started implementing this (two weeks ago). So we are making slow progress now. ... Just for the record: Chrome 9 with 2231/5987 is released. Furthermore, IE9RC supports the 2231/5987 encoding (UTF-8 only). So Safari is the last UA left not supporting this. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding priorities of subresource content retrieval
Finished testing a small patch: https://bugs.webkit.org/show_bug.cgi?id=54108 It only prioritizes script loading in body (not sure yet why doesn't work in head). Assuming most external-load slowdowns are caused by js from body vs anything from head, this should fix most horrific worst cases. Tested on http://solid.eqoppa.com/testlag2.html: First paint time unpatched: 80 seconds in First paint time patches: 34 seconds in Real-world test: http://technorati.com: First paint time unpatched: 5 seconds First paint time patched: 2 seconds Please help test and see if it breaks anything. Didn't see any breaks here yet :) If someone wants to help see if there will be any more improvement by adding the heuristic for js in head or for css in both head/body, please let know. For now, was thinking about twiddling with CachedResourceLoader::preload, but that might be too late if the engine already blocked on some css. p.s. if generally patches are discussed off-list, please kindly let know the correct venue. -- silvio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Which MIME type is best for JavaScript in WebKit?
Three regression tests are failing on one of my Macs. For local .js files I am getting the MIME type text/javascript and the tests expect application/x-javascript. I don’t know why I am getting different results on my computer than on, say, buildbots running the same version of Mac OS X. And also, I am wondering which MIME type is the one we want to see in WebKit for local JavaScript files. I can add Mac-specific code to the ResourceHandle implementation in WebKit to normalize this if that’s helpful. Does anyone know the answer to this or have a bug number to point me to? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Which MIME type is best for JavaScript in WebKit?
MIME types for JavaScript have a sad, painful history, largely related to the JavaScript/ECMAScript name fight and the IETF being unhelpful. For example, here's a note about this topic in the HTML5 specification: 8 Note: The term JavaScript is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329] 8 IMHO, we should use text/javascript as it is by far the most commonly used MIME type for JavaScript, despite what the IETF would have you believe. Adam On Sat, Feb 12, 2011 at 3:01 PM, Darin Adler da...@apple.com wrote: Three regression tests are failing on one of my Macs. For local .js files I am getting the MIME type text/javascript and the tests expect application/x-javascript. I don’t know why I am getting different results on my computer than on, say, buildbots running the same version of Mac OS X. And also, I am wondering which MIME type is the one we want to see in WebKit for local JavaScript files. I can add Mac-specific code to the ResourceHandle implementation in WebKit to normalize this if that’s helpful. Does anyone know the answer to this or have a bug number to point me to? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Which MIME type is best for JavaScript in WebKit?
I think I've seen that failure before. And I think I've fixed it by resetting my launch services. I think it may have started when I first launched DashCode. :) -eric On Sat, Feb 12, 2011 at 3:12 PM, Adam Barth aba...@webkit.org wrote: MIME types for JavaScript have a sad, painful history, largely related to the JavaScript/ECMAScript name fight and the IETF being unhelpful. For example, here's a note about this topic in the HTML5 specification: 8 Note: The term JavaScript is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329] 8 IMHO, we should use text/javascript as it is by far the most commonly used MIME type for JavaScript, despite what the IETF would have you believe. Adam On Sat, Feb 12, 2011 at 3:01 PM, Darin Adler da...@apple.com wrote: Three regression tests are failing on one of my Macs. For local .js files I am getting the MIME type text/javascript and the tests expect application/x-javascript. I don’t know why I am getting different results on my computer than on, say, buildbots running the same version of Mac OS X. And also, I am wondering which MIME type is the one we want to see in WebKit for local JavaScript files. I can add Mac-specific code to the ResourceHandle implementation in WebKit to normalize this if that’s helpful. Does anyone know the answer to this or have a bug number to point me to? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Which MIME type is best for JavaScript in WebKit?
On Feb 12, 2011, at 3:36 PM, Eric Seidel wrote: And I think I've fixed it by resetting my launch services. What does that mean, precisely? I’m familiar with Launch Services on Mac OS X, but not with a resetting procedure. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Which MIME type is best for JavaScript in WebKit?
sudo /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill will tell LS to delete its database (which it will then regen anew). see /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister --help for more options. My theory is that on affected systems some Application (I believe DashCode) is registering for .js with a different mimetype than the default (or other applications). Unfortunately, looking at: /Developer/Applications/Dashcode.app/Contents/Info.plist disproves my original theory that this incorrect mime type was added by DashCode: dict keyUTTypeConformsTo/key array stringcom.netscape.javascript-source/string /array keyUTTypeDescription/key stringDashcode JavaScript Document/string keyUTTypeIdentifier/key stringcom.apple.dashcode.javascript/string keyUTTypeReferenceURL/key stringhttp://www.apple.com/string keyUTTypeTagSpecification/key dict keypublic.filename-extension/key array stringjs/string /array keypublic.mime-type/key stringapplication/x-javascript/string /dict /dict -eric On Sat, Feb 12, 2011 at 5:19 PM, Darin Adler da...@apple.com wrote: On Feb 12, 2011, at 3:36 PM, Eric Seidel wrote: And I think I've fixed it by resetting my launch services. What does that mean, precisely? I’m familiar with Launch Services on Mac OS X, but not with a resetting procedure. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
