[webkit-dev] DOM rendering using Qt webkit bridge
Hi, Is it possible to display a QWidget on DOM (Div tag) using QtWebkit Bridge? For this we do not want to override QWebView's paint method. This is similar to NPAPI'S rendering, but utilizing QtWebkit Bridge. Also, as per QtWebkit Bridge documentation, we can get DOM objects as QWebElement in C++. But the example as provided in doc (http://doc.qt.nokia.com/4.7-snapshot/qtwebkit-bridge.html) does not work on Symbian. The Slot(QWebElement) is never called since MetaObject system is not able to find the slot. Any pointers?? Regards, Chandan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM rendering using Qt webkit bridge
Hi, On Fri, Mar 25, 2011 at 12:53 PM, Chandan Apsangi chandan...@gmail.comwrote: Is it possible to display a QWidget on DOM (Div tag) using QtWebkit Bridge? For this we do not want to override QWebView's paint method. This is similar to NPAPI'S rendering, but utilizing QtWebkit Bridge. Also, as per QtWebkit Bridge documentation, we can get DOM objects as QWebElement in C++. But the example as provided in doc (http://doc.qt.nokia.com/4.7-snapshot/qtwebkit-bridge.html) does not work on Symbian. The Slot(QWebElement) is never called since MetaObject system is not able to find the slot. Any pointers?? This is the wrong mailing list. The mailing list webkit-dev is about the development of WebKit itself. To get help for using QtWebKit, I suggest you to look at: -the forums: http://developer.qt.nokia.com/forums/viewforum/21/ -the webkit-qt mailinst list: http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt (the author of the QtWebKit bridge is on webkit-qt.) cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
Hi Brent, I definitely agree that gyp is rather undocumented and kind of hard to use. It's nowhere near the level of documentation of CMake, let alone Xcode or GNU makefiles. Hopefully we can fix this in the near future. That said, I'd be kind of surprised if cmake was already installed on your system, or scons, or xcode, or nmake, or just about anything except for make on Linux mac ;) -- Dirk On Thu, Mar 24, 2011 at 9:49 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Dimitri, LONG screed follows... On Mar 24, 2011, at 9:24 AM, Dimitri Glazkov wrote: \With the gyp conversion at this stage, we now have a possible solution to this problem. Given that there aren't any other viable alternatives in the present, please consider the most productive way of contributing: filing well-formulated bugs, blocking bug 55018 (https://bugs.webkit.org/showdependencytree.cgi?id=55018hide_resolved=1). We can then discuss these specific problems and adjust the shape of the solution accordingly. While I applaud the idea of a unified build system, my own experience trying to get gyp working has been a uniformly frustrating experience. Imagine for a moment that rather than being a Chromium developer, long schooled in the use of gyp and the various build components needed to support it, you are a lowly external developer who just wishes to build WebKit. Out of curiosity, I took a stab at playing with gyp again this evening: 1. The top Google hit for gyp build system takes me to an exhaustive specification of the gyp input file syntax format. If I click on the Project Home link, I find no information on downloading or installing the system. Presumably I can download the source and somehow generate the tool. 2. If I go to the User Documentation page (http://code.google.com/p/gyp/wiki/GypUserDocumentation), I am instructed on how to draft my own gyp files to build things. But why would I care when I can't even try the software out on an existing project, like WebKit? Once I download the gyp sources and 'build' them using the included setup.py, it's not clear what to do with them: link:Source brent$ gyp . Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp ./gyp Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp help Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ I kind of hate gyp! Compare that to the native Xcode projects, CMake files, or normal GNU Makefiles. These other solutions almost always JUST WORK, because if you can build any software on your machine, you must have used one of these options. I don't use gyp for anything, I don't have it installed, and its not clear how to go about using it. Please don't further raise the barrier of entry to new WebKit developers by adding yet another obscure build requirement to the system. :-( Thanks, -Brent ___ 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] UA string changes blog draft
Hello WebKit developers, I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. I've written a similar blog post, but focused on Chrome and aimed at a wider audience, that the Google folks intend to cross-post on both the Chromium and Google Webmaster Central blogs on Monday morning. I'd like to publish this draft at a similar time, barring objections. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting pkast...@google.com wrote: I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. Note, since this is a draft, you need to log in to blog.webkit.org to see it (creating an account is simple and free). For those who haven't logged in or don't wish to, here's the current fulltext. PK --- UA String Changes On WebKit Trunk http://www.webkit.org/blog/?p=1580Posted by *Peter Kasting* on Friday, March 25th, 2011 at 10:44 am Recently some changes to the UA string (tracked by https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4 (which you can read about at http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). Here’s a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here’s some sample post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 In detail, the differences are as follows: 1. On Windows, the initial “Windows;” platform identifier has been removed. This was redundant with the subsequent OS version identifier, and is more compatible with Internet Explorer, whose UA string doesn’t have this initial token. 2. The “U” SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are ”U” (for “USA” 128-bit encryption support), “I” (for “International” 40-bit encryption support), and “N“ (for “None”, no encryption support). These days, it’s unusual to ship without 128-bit SSL support everywhere; ports can add “I” or “N” if necessary. 3. On 64-bit versions of Windows, tokens have been added after the OS version. 32-bit builds running on 64-bit Windows have added “WOW64“. (”WOW64″ stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64; x64” for x64-based processors and “Win64; IA64” for Itanium systems. These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses. 4. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. 5. Windows CE builds should report the OS version slightly more accurately (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1“). Google intends to ship Chrome 11 with these changes, assuming they don’t cause major web compatibility problems, in order to get them into place as soon as possible after the Firefox 4 and IE 9 launches, and is already testing them in Chrome Dev and Beta channel builds. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
In addition to your comments, I also find the gyp syntax somewhat unpleasant. In particular, in .gypi lists of files to compile, ever entry is double-quoted, comma-separated, line-separated, and then grouped in multiple levels of braces. This is noisier than any of our current formats except the XML-based ones. It seems like a newline-separated list, possibly indented, should be sufficient. For .gyp files themselves, I admit I don't have a clear understanding of what they are actually doing, so it's hard for me to say if the syntax they use is good or not. I think in general the trick of making the files essentially Python code is (presumably) handy for Python experts but not easy to read for anyone else. But I am assuming syntax-level things can be fixed once we have things working for more ports, and doesn't necessarily need to be a showstopper to initial adoption. Perhaps after successfully deploying gyp for one additional port, the right next steps are to make sure the experience is smooth and enjoyable for WebKit hackers, before propagating it further. Regards, Maciej On Mar 24, 2011, at 9:49 PM, Brent Fulgham wrote: Hi Dimitri, LONG screed follows... On Mar 24, 2011, at 9:24 AM, Dimitri Glazkov wrote: \With the gyp conversion at this stage, we now have a possible solution to this problem. Given that there aren't any other viable alternatives in the present, please consider the most productive way of contributing: filing well-formulated bugs, blocking bug 55018 (https://bugs.webkit.org/showdependencytree.cgi?id=55018hide_resolved=1). We can then discuss these specific problems and adjust the shape of the solution accordingly. While I applaud the idea of a unified build system, my own experience trying to get gyp working has been a uniformly frustrating experience. Imagine for a moment that rather than being a Chromium developer, long schooled in the use of gyp and the various build components needed to support it, you are a lowly external developer who just wishes to build WebKit. Out of curiosity, I took a stab at playing with gyp again this evening: 1. The top Google hit for gyp build system takes me to an exhaustive specification of the gyp input file syntax format. If I click on the Project Home link, I find no information on downloading or installing the system. Presumably I can download the source and somehow generate the tool. 2. If I go to the User Documentation page (http://code.google.com/p/gyp/wiki/GypUserDocumentation), I am instructed on how to draft my own gyp files to build things. But why would I care when I can't even try the software out on an existing project, like WebKit? Once I download the gyp sources and 'build' them using the included setup.py, it's not clear what to do with them: link:Source brent$ gyp . Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp ./gyp Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ gyp help Traceback (most recent call last): File /usr/local/bin/gyp, line 18, in module sys.exit(gyp.main(sys.argv[1:])) File /Library/Python/2.6/site-packages/gyp/__init__.py, line 374, in main '--depth as a workaround.' Exception: Could not automatically locate src directory. This is a temporary Chromium feature that will be removed. Use --depth as a workaround. link:Source brent$ I kind of hate gyp! Compare that to the native Xcode projects, CMake files, or normal GNU Makefiles. These other solutions almost always JUST WORK, because if you can build any software on your machine, you must have used one of these options. I don't use gyp for anything, I don't have it installed, and its not clear how to go about using it. Please don't further raise the barrier of entry to new WebKit developers by adding yet another obscure build requirement to the system. :-( Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Mar 25, 2011, at 1:53 PM, Peter Kasting wrote: UA String Changes On WebKit Trunk Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am Recently some changes to the UA string (tracked by https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4 (which you can read about at http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). I find textual links, rather than bare URLs, more user-friendly. bug 54556 could be used as the text for the first link, at least. Here’s a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here’s some sample post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Here's should probably be Here are in both cases above. The “U” SSL encryption strength token has been removed. It is still present in the Mac UA strings you showed above. Thanks for writing the post! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
Hi Peter, I think you should say User Agent String in the title and maybe in the first paragraph say User Agent (UA) string, so that it's not quite as cryptic. The inline URLs are a bit ugly, perhaps some changes could be turned into a link to the tracking bug and similar changes in Firefox 4 could link to the mozilla.org post (and perhaps work in a link to http://blogs.msdn.com/b/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx). Here’s some sample post-change UA strings: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Presumably the U and en-u should be removed from this line? The draft also has a lot of (presumably Google Docs-induced) inline styles that it may be a good idea to clean up. Mihai On Fri, Mar 25, 2011 at 10:53 AM, Peter Kasting pkast...@google.com wrote: On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting pkast...@google.com wrote: I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. Note, since this is a draft, you need to log in to blog.webkit.org to see it (creating an account is simple and free). For those who haven't logged in or don't wish to, here's the current fulltext. PK --- UA String Changes On WebKit Trunk Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am Recently some changes to the UA string (tracked by https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4 (which you can read about at http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). Here’s a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here’s some sample post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 In detail, the differences are as follows: On Windows, the initial “Windows;” platform identifier has been removed. This was redundant with the subsequent OS version identifier, and is more compatible with Internet Explorer, whose UA string doesn’t have this initial token. The “U” SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are ”U” (for “USA” 128-bit encryption support), “I” (for “International” 40-bit encryption support), and “N“ (for “None”, no encryption support). These days, it’s unusual to ship without 128-bit SSL support everywhere; ports can add “I” or “N” if necessary. On 64-bit versions of Windows, tokens have been added after the OS version. 32-bit builds running on 64-bit Windows have added “WOW64“. (”WOW64″ stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64; x64” for x64-based processors and “Win64; IA64” for Itanium systems. These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. Windows CE builds should report the OS version slightly more accurately (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1“). Google intends to ship Chrome 11 with these changes, assuming they don’t cause major web compatibility problems, in order to get them into place as soon as possible after the Firefox 4 and IE 9 launches, and is already testing them in Chrome Dev and Beta channel builds. ___ 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] UA string changes blog draft
If you take a look at http://trac.webkit.org/browser/trunk/Source/WebKit/wince/WebCoreSupport/FrameLoaderClientWinCE.cpp#L57 I’m not sure if point 5 is correct. ;-) The WinCE port has still my initial UA string for testing. - Patrick _ From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Peter Kasting Sent: Friday, March 25, 2011 6:53 PM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] UA string changes blog draft On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting pkast...@google.com wrote: I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. Note, since this is a draft, you need to log in to blog.webkit.org to see it (creating an account is simple and free). For those who haven't logged in or don't wish to, here's the current fulltext. PK --- http://www.webkit.org/blog/?p=1580 UA String Changes On WebKit Trunk Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am Recently some changes to the UA string (tracked by https://bugs.webkit.org/show_bug.cgi?id=54556 https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4 (which you can read about at http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/ http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). Here’s a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here’s some sample post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 In detail, the differences are as follows: 1. On Windows, the initial “Windows;” platform identifier has been removed. This was redundant with the subsequent OS version identifier, and is more compatible with Internet Explorer, whose UA string doesn’t have this initial token. 2. The “U” SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are ”U” (for “USA” 128-bit encryption support), “I” (for “International” 40-bit encryption support), and “N“ (for “None”, no encryption support). These days, it’s unusual to ship without 128-bit SSL support everywhere; ports can add “I” or “N” if necessary. 3. On 64-bit versions of Windows, tokens have been added after the OS version. 32-bit builds running on 64-bit Windows have added “WOW64“. (”WOW64″ stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64; x64” for x64-based processors and “Win64; IA64” for Itanium systems. These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses. 4. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. 5. Windows CE builds should report the OS version slightly more accurately (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1“). Google intends to ship Chrome 11 with these changes, assuming they don’t cause major web compatibility problems, in order to get them into place as soon as possible after the Firefox 4 and IE 9 launches, and is already testing them in Chrome Dev and Beta channel builds. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer par...@paroga.comwrote: If you take a look at http://trac.webkit.org/browser/trunk/Source/WebKit/wince/WebCoreSupport/FrameLoaderClientWinCE.cpp#L57I’m not sure if point 5 is correct. ;-) The WinCE port has still my initial UA string for testing. My comments applied to the only WinCE-specific strings I had found, which were in the Qt port. I'll clarify that point. It should be easy for this code to do something like what the WebKit/win and WebKit2/win UA string code does, based on calling windowsVersionForUAString(), which should give correct output on Windows CE. You might want to file a bug to switch to that, if this port isn't dead. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
I've incorporated all the existing feedback into the draft. Feel free to take another look. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
The blog post begs the question made me wonder. Why was Macintosh; kept when it is redundant with Intel Mac OS X 10_6_7? The reasoning seem analogous to what was given for why Windows; was removed. dave On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.com wrote: I've incorporated all the existing feedback into the draft. Feel free to take another look. PK ___ 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] UA string changes blog draft
Ugh my strikethrough on begs the question was lost (and I meant that phrase as a joke). On Fri, Mar 25, 2011 at 11:54 AM, David Levin le...@google.com wrote: The blog post begs the question made me wonder. Why was Macintosh; kept when it is redundant with Intel Mac OS X 10_6_7? The reasoning seem analogous to what was given for why Windows; was removed. dave On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.comwrote: I've incorporated all the existing feedback into the draft. Feel free to take another look. PK ___ 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] UA string changes blog draft
WinCE port is not dead, but I don't have much time to implement/upstream new features at the moment :-( I filed bug 57111 and will post a patch. - Patrick _ From: Peter Kasting [mailto:pkast...@google.com] Sent: Friday, March 25, 2011 7:41 PM To: Patrick R. Gansterer Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] UA string changes blog draft On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer par...@paroga.com wrote: If you take a look at http://trac.webkit.org/browser/trunk/Source/WebKit/wince/WebCoreSupport/Fram eLoaderClientWinCE.cpp#L57 I'm not sure if point 5 is correct. ;-) The WinCE port has still my initial UA string for testing. My comments applied to the only WinCE-specific strings I had found, which were in the Qt port. I'll clarify that point. It should be easy for this code to do something like what the WebKit/win and WebKit2/win UA string code does, based on calling windowsVersionForUAString(), which should give correct output on Windows CE. You might want to file a bug to switch to that, if this port isn't dead. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 11:54 AM, David Levin le...@google.com wrote: The blog post begs the question made me wonder. Why was Macintosh; kept when it is redundant with Intel Mac OS X 10_6_7? The reasoning seem analogous to what was given for why Windows; was removed. Unlike Windows, the string Macintosh does not otherwise occur in the OS version. So sites looking for the token Macintosh to detect Macs will all break. Also, the main reason for both Gecko and WebKit to remove Windows was to match IE, which isn't a factor in the Mac UA string. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.com wrote: I've incorporated all the existing feedback into the draft. Feel free to take another look. Since some folks seem to be unable to see the draft even while logged in, here's the new fulltext. PK --- User Agent String Changes On WebKit Trunkhttp://www.webkit.org/blog/?p=1580Posted by *Peter Kasting* on Friday, March 25th, 2011 at 11:44 am Recently some changes to the User Agent (UA) stringhttps://bugs.webkit.org/show_bug.cgi?id=54556 have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/ . Here are a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here are the equivalent post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 In detail, the differences are as follows: 1. On Windows, the initial “Windows;” platform identifier has been removed. This was redundant with the subsequent OS version identifier, and is more compatible with Internet Explorer, whose UA string doesn’t have this initial token. 2. The “U” SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are “U” (for “USA” 128-bit encryption support), “I” (for “International” 40-bit encryption support), and “N” (for “None”, no encryption support). These days, it’s unusual to ship without 128-bit SSL support everywhere; ports can add “I” or “N” if necessary. 3. On 64-bit versions of Windows, tokens have been added after the OS version. 32-bit builds running on 64-bit Windows have added “WOW64”. (“WOW64” stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64; x64” for x64-based processors and “Win64; IA64” for Itanium systems. These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses. 4. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. 5. Windows CE builds of Qt-based ports should report the OS version slightly more accurately (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1”). As various ports ship these changes, you might notice web compatibility problems. If so, please point webmasters to this post, and/or file bugs in the bug tracker http://bugs.webkit.org/. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On 2011-03-25, at 12:07, Peter Kasting wrote: On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.com wrote: I've incorporated all the existing feedback into the draft. Feel free to take another look. Since some folks seem to be unable to see the draft even while logged in, here's the new fulltext. PK --- User Agent String Changes On WebKit Trunk Posted by Peter Kasting on Friday, March 25th, 2011 at 11:44 am Recently some changes to the User Agent (UA) string have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4. Here are the equivalent post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Is there some reason why these examples use manufactured Safari build numbers? It's implausible that a version of Safari with a build number of 534.24 would ever claim to be version 5.0.3. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote: Is there some reason why these examples use manufactured Safari build numbers? It's implausible that a version of Safari with a build number of 534.24 would ever claim to be version 5.0.3. Sorry, I wasn't sure what the right numbers were. What would be a more accurate number? I'd be happy to change it. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On 2011-03-25, at 12:56, Peter Kasting wrote: On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote: Is there some reason why these examples use manufactured Safari build numbers? It's implausible that a version of Safari with a build number of 534.24 would ever claim to be version 5.0.3. Sorry, I wasn't sure what the right numbers were. What would be a more accurate number? I'd be happy to change it. I'm not sure what you're asking here. Safari 5.0.3 will always report a build version of 533.19.4. Safari 5.0.4 will always report a build version of 533.20.27. You already used the former in your before examples. You have also been inconsistent about the WebKit version number. In the before version for the Mac user agent string you've included the + suffix that indicates an engineering build (from a local build or nightly). This isn't present in the Windows before version or either of the after versions. Since that component isn't relevant to the point you're trying to make it seems like it would be preferable for it to be consistent between examples. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-25, at 12:56, Peter Kasting wrote: On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote: Is there some reason why these examples use manufactured Safari build numbers? It's implausible that a version of Safari with a build number of 534.24 would ever claim to be version 5.0.3. Sorry, I wasn't sure what the right numbers were. What would be a more accurate number? I'd be happy to change it. I'm not sure what you're asking here. Safari 5.0.3 will always report a build version of 533.19.4. Safari 5.0.4 will always report a build version of 533.20.27. You already used the former in your before examples. You have also been inconsistent about the WebKit version number. In the before version for the Mac user agent string you've included the + suffix that indicates an engineering build (from a local build or nightly). This isn't present in the Windows before version or either of the after versions. Since that component isn't relevant to the point you're trying to make it seems like it would be preferable for it to be consistent between examples. Ideally, I would like the Safari-on-Windows and Safari-on-Mac strings from a trunk build as of around the time my change landed, which I'd use as the identical before and after strings, and only change the portions actually affected by the UA changes that landed. I don't have the ability to build either of those myself right now, so what you're seeing is a combination of internet research, inference from Chromium builds, and mistakes in copy and pasting. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
