Qt's default webkit user agent
As it is today Qt's default user agent (in qwebpage.cpp) is hard coded to: "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.15 (KHTML, like Gecko) Safari/419.3 Qt" Seeing as this library will be used inside of many other applications it makes sense to include by default at least the application name/version when they are set. QCoreApplication gives us several strings which can be used. applicationName, applicationVersion, organizationDomain, organizationName But at a bigger question, what should be included (or not included) with the default user agent? Is there docs anywhere that suggest what webkit library users should use as their user agent string? -Benjamin Meyer
Benjamin Meyer wrote:
As it is today Qt's default user agent (in qwebpage.cpp) is hard coded to:
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.15 (KHTML, like Gecko) Safari/419.3 Qt"
Seeing as this library will be used inside of many other applications it makes sense to include by default at least the application name/version when they are set. QCoreApplication gives us several strings which can be used.
applicationName, applicationVersion, organizationDomain, organizationName
But at a bigger question, what should be included (or not included) with the default user agent? Is there docs anywhere that suggest what webkit library users should use as their user agent string?
We did some research for the GTK+ port and tried to integrate the most important UA string compatibility hacks without making the string too ugly. The code in WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp documents each UA string element with comments. It's fairly general and is intended to be moved down into WebCore. If you decide to use this code, please submit any fixes through the bug tracker. Hope it helps. (It's disappointing to see the growing number of WebCore changes in Qt's git tree that could benefit the whole project. Are you planning to submit these changes for review?)
On Tuesday 12 February 2008, Alp Toker wrote:
(It's disappointing to see the growing number of WebCore changes in Qt's git tree that could benefit the whole project. Are you planning to submit these changes for review?)
All of our changes are supposed to go into trunk. This is not always happening immediately unfortunately, but we currently have merged all changes until two weeks ago into trunk. So saying the number of changes in our tree is growing is IMO not really correcy. We're currently trying to get our Qt 4.4 beta out, and are therefore a bit slow with merging and submitting our changes. But one large change we did (fixing a crash with navigator.plugins and autogenerating the bindings) is now hanging in the review queue for almost 4 weeks. We currently can't afford to wait that long for some fixes to go in. Most of us can't hang our on IRC late every evening neither which seems to be often a requirement to push things forward. As I said earlier, we don't like working outside svn, but with having a deadline to release a product and with WebKit trunk currently moving ahead and implementing new features we didn't really have a choice. Lars
You have to be careful when changing the UA as there are sites that do the most absurd checks. For example including applicationVersion could easily trigger WebKit to be detected as another (probably much older) browser -- i believe it is necessary to avoid ever having the string "4." in the UA for example as there are used to be) sites that assume that indexOf("4.") != -1 means the your browser is netscape 4 and supports the layers extension, eg. as done at http://www.sloppycode.net/code-snippets/javascript/web-safe-palette.aspx (This page works unless there's a 4 in the UA version) So at the very least i would be careful about including version info, you also can't remove Mozilla/5.0, WebKit, KHTML, Gecko, or Safari because people look for those substrings (Mozilla/5.0 means you're not IE -- although there's also a more modern version where "Firefox" means not IE and that breaks at least one site i know of and use *grumble*) All in all i'll just reiterate that changes to the UA flags are *dangerous* and can easily cause sites to "break" --Oliver On Feb 12, 2008, at 1:38 AM, Benjamin Meyer wrote:
As it is today Qt's default user agent (in qwebpage.cpp) is hard coded to:
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.15 (KHTML, like Gecko) Safari/419.3 Qt"
Seeing as this library will be used inside of many other applications it makes sense to include by default at least the application name/version when they are set. QCoreApplication gives us several strings which can be used.
applicationName, applicationVersion, organizationDomain, organizationName
But at a bigger question, what should be included (or not included) with the default user agent? Is there docs anywhere that suggest what webkit library users should use as their user agent string?
-Benjamin Meyer _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
As reported earlier the r38760 build caused a 5% degradation in performance on my MBP 17. Now the r38826 build has caused a further degradation. During this period the Safari browser has maintained a score of about 3300. Prior to r38760 - about 830 After r38760 - about 870 After r38826 - about 900 Please let me now if I'm the only one seeing this degradation and I'll check for any other possible explanations. - Dave
On Nov 28, 2008, at 12:18 AM, Dave Cronk wrote:
As reported earlier the r38760 build caused a 5% degradation in performance on my MBP 17. Now the r38826 build has caused a further degradation. During this period the Safari browser has maintained a score of about 3300.
Prior to r38760 - about 830 After r38760 - about 870
<http://trac.webkit.org/changeset/38760> As mentioned before, this commit has no effect on the code, so any significant performance degradation that you are measuring here puts your methodology in question. Are your results repeatable?
After r38826 - about 900
<http://trac.webkit.org/changeset/38826> This also looks like it's unlikely to have performance impact. Simon
On Nov 28, 2008, at 3:18 AM, Dave Cronk wrote:
As reported earlier the r38760 build caused a 5% degradation in performance on my MBP 17. Now the r38826 build has caused a further degradation. During this period the Safari browser has maintained a score of about 3300.
Prior to r38760 - about 830 After r38760 - about 870 After r38826 - about 900
Please let me now if I'm the only one seeing this degradation and I'll check for any other possible explanations.
It sounds like you're running nightly builds. I think some other responders to this thread have assumed that you meant that the actual code change that resulted in r38760 being committed to Subversion caused a performance regression, while what you really mean (I think) is that the r38760 nightly build is slower than some nightly build prior to it. Can you tell us which builds you ran and the "score" you obtained for each? (How was the "score" determined, btw?) -Adam
participants (7)
-
Adam Roben
-
Alp Toker
-
Benjamin Meyer
-
Dave Cronk
-
Lars Knoll
-
Oliver Hunt
-
Simon Fraser