Re: [webkit-dev] UA string changes blog draft

[Peter Kasting]

On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe  wrote:

> On 2011-03-25, at 12:56, Peter Kasting wrote:
>
> On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe  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

Re: [webkit-dev] UA string changes blog draft

[Mark Rowe]

On 2011-03-25, at 12:56, Peter Kasting wrote:

> On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe  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

[Peter Kasting]

On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe  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

[Mark Rowe]

On 2011-03-25, at 12:07, Peter Kasting wrote:

> On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting  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

[Peter Kasting]

On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting  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
TrunkPosted
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 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 .
___
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

[Peter Kasting]

On Fri, Mar 25, 2011 at 11:54 AM, David Levin  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

[Patrick R. Gansterer]

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 
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

[David Levin]

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  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 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

[David Levin]

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  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

[Peter Kasting]

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

[Peter Kasting]

On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer wrote:

>  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

[Patrick R. Gansterer]

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  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:

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

[Mihai Parparita]

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  wrote:
> On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting  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

[Maciej Stachowiak]

Looks ok. Usually we stay away from mentioning changes in or plans for specific 
WebKit-based browsers rather than WebKit itself on the blog, when possible, so 
I suggest replacing the last paragraph with a general encouragement to help 
find compatibility problems with these changes.

 - Maciej

On Mar 25, 2011, at 10:53 AM, Peter Kasting wrote:

> On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting  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

[Adam Roben]

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] Build system update

[Maciej Stachowiak]

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,
> 
> 
> 
> 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=55018&hide_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 
>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 
>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 
>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

[Peter Kasting]

On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting  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:

   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

[webkit-dev] UA string changes blog draft

[Peter Kasting]

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] Build system update

[Dirk Pranke]

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  wrote:
> Hi Dimitri,
>
> 
>
> 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=55018&hide_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 
>    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 
>    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 
>    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

Re: [webkit-dev] DOM rendering using Qt webkit bridge

[Benjamin]

Hi,

On Fri, Mar 25, 2011 at 12:53 PM, Chandan Apsangi wrote:

> Is it possible to display a QWidget on DOM ( 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

[webkit-dev] DOM rendering using Qt webkit bridge

[Chandan Apsangi]

Hi,

Is it possible to display a QWidget on DOM ( 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