Elide long emails in the wrench and profile menus.

ui/base/text/text_elider.cc

Index: ui/base/text/text_elider.cc
diff --git a/ui/base/text/text_elider.cc b/ui/base/text/text_elider.cc
index 525cea0df61eb373507b91372f144dbf327cf419..07b74fa60af61afba9b43b07143c6fc588f888a8 100644
--- a/ui/base/text/text_elider.cc
+++ b/ui/base/text/text_elider.cc
@@ -149,12 +149,60 @@ string16 ElideComponentizedPath(const string16& url_path_prefix,
 
 }  // namespace
 
-// This function takes a GURL object and elides it. It returns a string
-// which composed of parts from subdomain, domain, path, filename and query.
-// A "..." is added automatically at the end if the elided string is bigger
-// than the available pixel width. For available pixel width = 0, a formatted,
-// but un-elided, string is returned.
-//
+string16 ElideEmail(const string16& email,
+                    const gfx::Font& font,
+                    int available_pixel_width) {
+  if (font.GetStringWidth(email) <= available_pixel_width)
+    return email;
+
+  std::vector<string16> email_split;
+  base::SplitString(email, '@', &email_split);

[sky, 2012/03/06 16:56:16]

Are you sure this is right? The spec seems to indicate the local-part can have
embedded @s in it.

[gab, 2012/03/06 22:06:21]

I spent a while today looking through code search trying to find an existing
method to validate emails (in all possible forms as described here:
http://en.wikipedia.org/wiki/Email_address#Local_part).

There is nothing in current Chromium code that validates email addresses
correctly: the only thing I could find is a regex in depot_tools that doesn't
encompass all possibilities in the email spec: http://goo.gl/UR7X5)

I also found that ChromeOS's email canonicalizer assumes the same that I did
(about a single @ symbol per email address):
http://code.google.com/codesearch#OAMlx_jo-ck/src/chrome/browser/chromeos/log...

As it is now, this function is only to be used to elide emails returned from
logged in GAIA profiles (does GAIA support the full email spectrum? If not, I
could change the name of my function to ElideGAIAEmail or simply add a comment
to make it clear it doesn't support the full email spectrum).

+  DCHECK_EQ(email_split.size(), 2U);
+  string16 username = email_split.front();
+  string16 domain = email_split.back();
+
+  const string16 kEllipsisUTF16 = UTF8ToUTF16(kEllipsis);
+
+  // Subtract the @ symbol from the available width as it is mandatory.
+  const string16 kAtSignUTF16 = ASCIIToUTF16("@");
+  available_pixel_width -= font.GetStringWidth(kAtSignUTF16);
+
+  // Check whether eliding the domain is necessary: if eliding the username
+  // is sufficient, the domain will not be elided.
+  const int full_username_width = font.GetStringWidth(username);
+  const int available_domain_width =
+      available_pixel_width -
+      std::min(full_username_width,

[gab, 2012/03/02 23:37:21]

I just realized that if the full username is smaller than its first letter +
ellipsis, we could be forcing the domain to elide when it didn't need to.

The new test: {"l@lllllllll.com", "l@lllll" + kEllipsisStr + ".com"}
confirms this (i.e. it fails if you remove this min calculation and passes now)

+               font.GetStringWidth(username.substr(0, 1) + kEllipsisUTF16));
+  if (font.GetStringWidth(domain) > available_domain_width) {
+    // Elide the domain so that it only takes half of the available width.
+    // Should the username not need all the width available in its half, the
+    // domain will occupy the leftover width.
+    // If |desired_domain_width| is greater than |available_domain_width|: the
+    // minimal username elision allowed by the specifications will not fit; thus
+    // |desired_domain_width| must be <= |available_domain_width| at all cost.
+    const int desired_domain_width =
+        std::min(available_domain_width,
+                 std::max(available_pixel_width - full_username_width,
+                          available_pixel_width / 2));

[gab, 2012/03/02 23:37:21]

@asvitkine re-thinking about it: you were right :)!

I decided to do all the logic here so that if we do make it to the username
eliding we are 100% sure there is enough space to respect the spec and don't
need to further check the result of the 2nd elide.

I was able to construct a test: {"mmm@llllll", "m" + kEllipsisStr + "@l" +
kEllipsisStr + "l"}
 in which the |desired_domain_width| without the min would result in a number
larger than the |available_domain_width| (which means we could potentially leave
the domain too big and be left with not enough room for the username when a
resolution was actually possible).
Under my fonts in Ubuntu however this test didn't fail without the min as
unluckily it turned out that (desired_domain_width == 23, available_domain_width
== 21, but unluckily the elided string turned out to be 21 as well (as elision
doesn't guarantee an exact fit obviously)...)

I tested/observed this by adding:
    if(std::max(available_pixel_width - full_username_width,
                available_pixel_width / 2) > available_domain_width){
      LOG(INFO) << "HEEERRRRRRRRRRRRRRRREEEEEEEEEEEEEEEEEEEEEEEE";

      LOG(INFO) << "desired: " << desired_domain_width;
      LOG(INFO) << "avail_dom: " << available_domain_width;
      LOG(INFO) << "avail_pix: " << available_pixel_width;
      LOG(INFO) << "full_username_width:" << full_username_width;
      LOG(INFO) << "final_dom:" << font.GetStringWidth(domain);
    }
to the end of the domain eliding if block and seeing that in the previous
version without the min: the desired width would come out bigger than the
available width. This new min fixes this problem.

+    domain = ElideText(domain, font, desired_domain_width, ELIDE_IN_MIDDLE);
+    // Failing to elide the domain such that at least one character remains
+    // (other than the ellipsis itself) remains: return a single ellipsis.
+    if (domain.length() <= 1U)
+      return kEllipsisUTF16;
+  }
+
+  // Fit the username in the remaining width (at this point the elided username
+  // is guaranteed to fit with at least one character remaining given all the
+  // precautions taken earlier).
+  username = ElideText(username,
+                       font,
+                       available_pixel_width - font.GetStringWidth(domain),
+                       ELIDE_AT_END);
+
+  return username + kAtSignUTF16 + domain;
+}
+
 // TODO(pkasting): http://crbug.com/77883 This whole function gets
 // kerning/ligatures/etc. issues potentially wrong by assuming that the width of
 // a rendered string is always the sum of the widths of its substrings.  Also I
@@ -393,8 +441,6 @@ string16 ElideFilename(const FilePath& filename,
   return base::i18n::GetDisplayStringInLTRDirectionality(elided_name);
 }
 
-// This function adds an ellipsis at the end of the text if the text
-// does not fit the given pixel width.
 string16 ElideText(const string16& text,
                    const gfx::Font& font,
                    int available_pixel_width,