|
|
Created:
6 years, 6 months ago by Will Harris Modified:
6 years, 6 months ago Reviewers:
Bernhard Bauer CC:
chromium-reviews Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionAdd "64-bit" to Chrome's 'about' page.
Finding whether you are running 64-bit or 32-bit is proving tricky for users
since the chrome://version page is not linked anywhere.
This adds "64-bit" string to the chrome://chrome page for 64-bit builds.
BUG=381246
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276592
Patch Set 1 #
Messages
Total messages: 13 (0 generated)
Hi bauerb@ - Interested in your views on this. We're getting users reporting that they can't tell whether they are 64-bit or 32-bit on both Windows and Mac. the version is available by looking in chrome://version and inspecting the user agent, but this isn't entirely obvious. Thoughts on adding a "64-bit" string to the main chrome://chrome page?
On 2014/06/09 22:09:08, Will Harris wrote: > Hi bauerb@ - Interested in your views on this. > > We're getting users reporting that they can't tell whether they are 64-bit or > 32-bit on both Windows and Mac. > > the version is available by looking in chrome://version and inspecting the user > agent, but this isn't entirely obvious. > > Thoughts on adding a "64-bit" string to the main chrome://chrome page? I'm definitely in favor of exposing that information. I'm just leaning towards putting it into chrome::VersionInfo::GetVersionStringModifier(), so it will be available in more places. Aura and SyzyAsan builds seem to have done it that way. One thing to watch out for is that that will also change e.g. the "channel" identifier (which isn't exactly the channel) on crash/, but I don't think it's necessarily a bad idea to separate 64-bit crashes from 32-bit ones. Out of curiosity, how do you do that today?
On 2014/06/10 07:47:49, Bernhard Bauer wrote: > On 2014/06/09 22:09:08, Will Harris wrote: > > Hi bauerb@ - Interested in your views on this. > > > > We're getting users reporting that they can't tell whether they are 64-bit or > > 32-bit on both Windows and Mac. > > > > the version is available by looking in chrome://version and inspecting the > user > > agent, but this isn't entirely obvious. > > > > Thoughts on adding a "64-bit" string to the main chrome://chrome page? > > I'm definitely in favor of exposing that information. I'm just leaning towards > putting it into chrome::VersionInfo::GetVersionStringModifier(), so it will be > available in more places. Aura and SyzyAsan builds seem to have done it that > way. > > One thing to watch out for is that that will also change e.g. the "channel" > identifier (which isn't exactly the channel) on crash/, but I don't think it's > necessarily a bad idea to separate 64-bit crashes from 32-bit ones. Out of > curiosity, how do you do that today? The channel version string reported by Omaha already reports 64-bit - e.g. versions come up as 37.0.2036.0 and 37.0.2036.0-64 and we already have some processing that relies on that, so I didn't want to play with it too much. I'm a bit worried about playing with GetVersionStringModifier() - it seems to be used in several places to detect the channel - by e.g. detecting stable channel by looking for empty string e.g. about_sync_util.cc uses this method. I'm worried about any changes here might have some unexpected knock-on effects. Therefore, I think I'd just like to make it a visual change on the chrome://chrome page. What do you think?
On Tue, Jun 10, 2014 at 4:55 PM, <wfh@chromium.org> wrote: > On 2014/06/10 07:47:49, Bernhard Bauer wrote: > >> On 2014/06/09 22:09:08, Will Harris wrote: >> > Hi bauerb@ - Interested in your views on this. >> > >> > We're getting users reporting that they can't tell whether they are >> 64-bit >> > or > >> > 32-bit on both Windows and Mac. >> > >> > the version is available by looking in chrome://version and inspecting >> the >> user >> > agent, but this isn't entirely obvious. >> > >> > Thoughts on adding a "64-bit" string to the main chrome://chrome page? >> > > I'm definitely in favor of exposing that information. I'm just leaning >> towards >> putting it into chrome::VersionInfo::GetVersionStringModifier(), so it >> will be >> available in more places. Aura and SyzyAsan builds seem to have done it >> that >> way. >> > > One thing to watch out for is that that will also change e.g. the >> "channel" >> identifier (which isn't exactly the channel) on crash/, but I don't think >> it's >> necessarily a bad idea to separate 64-bit crashes from 32-bit ones. Out of >> curiosity, how do you do that today? >> > > The channel version string reported by Omaha already reports 64-bit - e.g. > versions come up as 37.0.2036.0 and 37.0.2036.0-64 and we already have some > processing that relies on that, so I didn't want to play with it too much. > Hm, breakpad doesn't seem to though. > I'm a bit worried about playing with GetVersionStringModifier() - it seems > to be > used in several places to detect the channel - by e.g. detecting stable > channel > by looking for empty string e.g. about_sync_util.cc uses this method. I'm > worried about any changes here might have some unexpected knock-on effects. > In that particular case, the code wants to detect a developer build, which also has a false positive for a stable channel version, so making a 64-bit stable channel version *not* return an empty string is not going to break that logic. I see your point though. > Therefore, I think I'd just like to make it a visual change on the > chrome://chrome page. What do you think? > I still feel we are adding more hacks to work around the existing hacks instead of cleaning them up, but at least this one is going to be restricted to chrome://chrome, so LGTM. > https://codereview.chromium.org/326773003/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
This time from Rietveld: LGTM
The CQ bit was checked by wfh@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/wfh@chromium.org/326773003/1
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was checked by wfh@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/wfh@chromium.org/326773003/1
Message was sent while issue was closed.
Change committed as 276592 |