Bug 124454 - [Win] WebKit version in user agent string is incorrect.
Summary: [Win] WebKit version in user agent string is incorrect.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 124548
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-16 08:31 PST by peavo
Modified: 2013-11-25 15:06 PST (History)
4 users (show)

See Also:


Attachments
Patch (3.21 KB, patch)
2013-11-16 08:35 PST, peavo
no flags Details | Formatted Diff | Diff
Patch (3.05 KB, patch)
2013-11-20 12:39 PST, peavo
no flags Details | Formatted Diff | Diff
Patch (5.21 KB, patch)
2013-11-25 13:33 PST, peavo
no flags Details | Formatted Diff | Diff
Patch (7.47 KB, patch)
2013-11-25 14:41 PST, peavo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description peavo 2013-11-16 08:31:06 PST
The WebKit version in the user agent string is outdated, it says "534+".
Comment 1 peavo 2013-11-16 08:35:46 PST
Created attachment 217125 [details]
Patch
Comment 2 Brent Fulgham 2013-11-18 10:20:02 PST
Comment on attachment 217125 [details]
Patch

Nice!  r=me.
Comment 3 WebKit Commit Bot 2013-11-18 10:23:15 PST
Comment on attachment 217125 [details]
Patch

Clearing flags on attachment: 217125

Committed r159430: <http://trac.webkit.org/changeset/159430>
Comment 4 WebKit Commit Bot 2013-11-18 10:23:16 PST
All reviewed patches have been landed.  Closing bug.
Comment 5 peavo 2013-11-18 11:00:53 PST
(In reply to comment #2)
> (From update of attachment 217125 [details])
> Nice!  r=me.

Thanks for reviewing :)
Comment 6 WebKit Commit Bot 2013-11-18 16:51:38 PST
Re-opened since this is blocked by bug 124548
Comment 7 Tim Horton 2013-11-18 16:56:45 PST
If you want to do this, you'll have to do it in a way that doesn't involve reaching across the project boundary for random files.
Comment 8 peavo 2013-11-20 12:39:24 PST
Created attachment 217466 [details]
Patch
Comment 9 peavo 2013-11-20 12:41:29 PST
(In reply to comment #7)
> If you want to do this, you'll have to do it in a way that doesn't involve reaching across the project boundary for random files.

Trying again :)

I moved everything into the WebKit folder, and did not alter the user agent for WinApple, only WinCairo, to be on the safe side.
Comment 10 Brent Fulgham 2013-11-21 10:48:33 PST
Comment on attachment 217466 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=217466&action=review

A really great idea.  I think it needs a little bit of refinement to be right. I'd also like the Apple version to use your logic.

> Source/WebKit/ChangeLog:8
> +        * WebKit.vcxproj/WebKit/WebKitPreBuild.cmd: Generate WebKitVersion.h

... from OS X Version.xcconfig input file.

> Source/WebKit/WebKit.vcxproj/WebKit/WebKitPreBuild.cmd:11
>  bash "%WEBKIT_LIBRARIES%\tools\scripts\auto-version.sh" "%INTDIR%"

auto-version.sh is supposed to do something clever about version, but I see that its input file is set to 534, rather than 538 (which is what we have in Version.xcconfig).

I much prefer your approach, which allows us to control version in one place and keep them in sync.

> Source/WebKit/WebKit.vcxproj/WebKit/WebKitPreBuild.cmd:17
> +if not exist "%WEBKITVERSIONFILE%" bash -c 'perl "%WEBKITVERSIONSCRIPT%" --config "%WEBKITVERSIONCONFIG%"  --outputDir "%WEBKITVERSIONDIR%"'

You need to make sure that %WEBKITVERSIONFILE% is deleted when you clean the project, or else it will never update when the value in Version.xcconfig changes.

We should ideally drive generation of the version file based on changes to Version.xcconfig, but I'm not sure how we would do so in Visual Studio. We could add Version.xcconfig to the WebKit solution with a custom build step that would do this work, rather than having it done as part of WebKitPreBuild.cmd.

Either way, this is wrong because you will get one version number from Version.xcconfig, and then it will never change again unless you delete the file.

> Source/WebKit/win/WebView.cpp:2500
> +#endif

Please revise as follows:

#if !USE(CAIRO)
LPWSTR buildNumberStringPtr;
if (::LoadStringW(gInstance....)
    return buildNumberStringPtr;
#endif

    return String::format("%d.%d", WEBKIT_MAJOR_VERSION, WEBKIT_MINOR_VERSION);
}
Comment 11 peavo 2013-11-25 13:33:58 PST
Created attachment 217826 [details]
Patch
Comment 12 peavo 2013-11-25 13:36:06 PST
(In reply to comment #10)
> (From update of attachment 217466 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=217466&action=review
> 

Thanks for looking into this, I added a custom build step to build WebKitVersion.h as you suggested :)
Comment 13 Build Bot 2013-11-25 14:15:00 PST
Comment on attachment 217826 [details]
Patch

Attachment 217826 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/35368558
Comment 14 peavo 2013-11-25 14:41:39 PST
Created attachment 217834 [details]
Patch
Comment 15 Brent Fulgham 2013-11-25 15:02:32 PST
Comment on attachment 217834 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=217834&action=review

Looks great! You might want to omit the macro as I describe below. But it's fine as-is. R=me.

> Source/WebKit/win/WebView.cpp:2492
> +#if !USE(CAIRO)

I'm not sure that we need this macro at all. If WinCairo doesn't define BUILD_NUMBER it should just do the right thing. That way, you can define it yourself for future builds.
Comment 16 WebKit Commit Bot 2013-11-25 15:06:16 PST
Comment on attachment 217834 [details]
Patch

Clearing flags on attachment: 217834

Committed r159768: <http://trac.webkit.org/changeset/159768>
Comment 17 WebKit Commit Bot 2013-11-25 15:06:19 PST
All reviewed patches have been landed.  Closing bug.