The extension badging problem is real, and tracked elsewhere.

A lot of the address bar font issues, I think, were probably for users on 125% scale, where until recently Chrome was forcing 100% scale.  We now respect 125%, which should make things more readable in these cases.

For other users/after that fix, we should basically match Edge and Firefox, and we don't intend to make changes.  Whole-screen screenshots of Chrome-vs.-something else better on actual user systems would be helpful context if people still feel like things are not OK.

> A lot of the address bar font issues, I think, were probably for users on 125% scale, where until recently Chrome was forcing 100% scale.  We now respect 125%, which should make things more readable in these cases.

Is that consistent with all of the complaints happening after the upgrade to M55? Every one of the users who posted said this regressed for them in the past 2 weeks, and those who provided version numbers all gave 55.0.2883.87.

I don't know when the 125% fix changed, but if these are M54->M55 changes, they aren't about MD, which shipped earlier.  That coupled with the fact that we really did make the font size smaller in the MD omnibox is confusing me here about exactly what users are really reporting.

Specific screenshots of a change from 54 -> 55 to clarify what issue is in play here would help.

FYI, I'm running at 100% font scaling.  I refuse to use any scaling whatsoever.

http://i.imgur.com/nQp07Yk.jpg

Here's my non-material vs material with the exact same tabs.  Note the differences:
* Icon/Font for badge icons needlessly small.  It's not saving any space.
* Fewer characters readable on each tab.
* I don't mind the address bar font shrinking, but it's affecting many others.

Again, I don't see the point of the change.  We should be able to turn it off if it doesn't suit us.

Before/after screenshots from one user:

https://i.imgur.com/KPpyMdd.png
https://i.imgur.com/AYJkdqp.png

In a paint editor, the height of the first lowercase 'h' in the url changed from 12 pixels high to 10 pixels high.

> Again, I don't see the point of the change.  We should be able to turn it off if it doesn't suit us.

It's sounding like most users are not seeing an omnibox font size difference in M55, but a substantial number are.

@7: That's a screenshot of pre-MD vs. post-MD, so that would be the intentional change we made (i.e.  bug 615405 ), not something that changed in M55 specifically.

@6: Yup, those are all MD-vs.-non-MD differences.  The badge icon issue is bug 649054.

@8: Definitely still interested in a change that is M55-specific, that would be distinct from how I originally duped here.

> @7: That's a screenshot of pre-MD vs. post-MD, so that would be the intentional change we made (i.e.  bug 615405 ), not something that changed in M55 specifically.

So if I understand correctly,  bug 615405  is from an early version of MD when it was experimental / behind a flag, and the only difference in 55 is that we shipped it to all users?

No, we shipped MD to all users by M53.  "MD" and "M55" should be unrelated to each other.

The Reddit thread here asked about MD, and the screenshots are of MD, so I think the context is MD, and the "what version are you on? -- 55" is simply a reflection that M55 is current stable.  I've not yet seen anything concrete about a real M54 -> M55 change here.  I believe there could be one, but I don't know what it is.

@9 The M55-specific change is that we can no longer revert to non-MD.

When MD first came out back in September or so, we could change to non-MD and we quieted down at that point.

Now, that flag is gone, so people are loud again because there's nothing we can do anymore.

Ah, that could be it.  We have been rapidly breaking down the functionality of that flag, but I hadn't been clear on exactly which release would remove it entirely, as opposed to just making it not work right.

Tentatively re-duping.  Suspect any M55-specific change here is for people that had this force-disabled in flags, who are now getting MD.

The loss of the flag to revert back to Non-Material Design is definitely what has triggered all the complaints. Prior to Chrome v55 those who preferred Non-Material Design had been using the "#top-chrome" flag - and were content - now they have no option but to complain - as the override has been removed . The smaller omnibox fonts and smaller, lower contrast icons are a problem for all with less than perfect eyesight. 

To be clear, this bug is about the omnibox font, and our viewpoint on this is that it's not an accessibility problem -- it's already larger than the default system font, or the default web content font, and as large as the similar fonts in Edge and Firefox.  Our assumption is that users for whom this size is still problematic will generally by using system-wide zooming (e.g. to 125%+), and we've focused on making Chrome more accessible by making it work better at those sorts of zoom factors.

There's definitely also an individual preference thing in play as well, but that one is true both ways -- we got tons of hate mail when we first enlarged the font from its current size to the larger size we used until M53 telling us that "I don't need a fifty point font to read" and "I'm not an idiot, don't treat me like one" and "you made the browser look like a child's plaything".  We're more willing to live with disappointing individual taste than we are with making things inaccessible -- but we don't think this change has created an accessibility problem.

How is making the font smaller/unreadable not an accessibility issue when users with not so sharp vision can't read their extension badges anymore?  Using 125% font scaling does not solve the problem without creating another and the badge numbers in Chrome still look unclear and hard to read.  It's just a poor readability font to use.  It's clearly not the same font as that other browsers are using as users are already stating that they're jumping ship for Firefox, Vivaldi, or Edge.  Even worse, the current fix going around is installing a stand-alone version of Chrome 54 with Google Updates disabled.

This bug is not about extension badges, which we agree ARE an accessibility issue.  As stated on comment 9, badges are bug 649054.

This is ONLY about the omnibox font.  If you have a screenshot demonstrating that actually being perceptibly smaller than Edge/Firefox, I would be interested.

pkasting,

Why are you only interested in Chrome vs other browsers? You need to focus on your browser, making it the best it can be. Just because other browsers have less easy to read font sizes, it does mean you should strive for that also.

The entire industry has always been moving towards higher DPI forever, and going in the opposite direction doesn't make any sense to me.

The thing that really astounds me is how MD has made the UI take up more space somehow while decreasing the font size. If there was a useful trade-off between UI size reductions and usable browser are then at least it would be understandable.

Chrome used to be the industry leader by a country mile...

IMHO, aside from people being used to the font size (I probably wasn't using Chrome back when the said enlargement happened @18), maybe the issue is that the address is not text you focus on to read, it's something you want to get in a quick look. It's somewhat like making the title of something have the same size of the body text.

I agree with @21 in that it doesn't make much sense to compare browsers, I only use Firefox for tests when things get messed in Chrome or so. Also, I don't have to "system-wide zoom" to enlarge webpages that are too small for me.

@21: Other browsers are cited as a data point: if Chrome's address bar is egregiously non-accessible, everyone's address bars are.  The fact that several different major vendors with a commitment to accessibility have shipped address bars with this size font for years and no one has changed it suggests (though it does not prove) that perhaps this is not, in fact, an accessibility problem.  (I include Chrome in the "for years" bucket since we shipped this size font for years, and when we enlarged it, we didn't do so to improve accessibility.)

I don't know what you mean by "The entire industry has always been moving towards higher DPI forever, and going in the opposite direction doesn't make any sense to me."  Nothing about our change is focused on low DPI.  As stated in comment 18, we're actually putting a lot of work into working better at higher DPI and fixing issues that caused the whole UI to be too small.  Changing the omnibox font size within the UI is orthogonal to the issue of working well on high DPI.

Ah, sorry, pkasting re:@20, I misunderstood the focus of this ticket.  I did grab a couple screenshots yesterday comparing this page with current version of Chrome and Edge for my own interest.  Out of simple preference, I don't like the new omnibox font compared to the previous version, but it is still readable to me.  I think Edge's "omnibox" text is a bit sharper looking albeit just a smidge slimmer, but the general top chrome of Edge is a bit thicker overall.

Deleted: Chrome-Edge-stacked.PNG 10.7 KB

	Chrome-Edge-stacked.PNG 10.7 KB View Download

Deleted: Chrome-Edge-side-by-side.PNG 58.1 KB

	Chrome-Edge-side-by-side.PNG 58.1 KB View Download

Weirdly, Edge's font has the same character heights (ascent, descent, x-height), but a more compressed horizontal presentation.  They're also using greyscale AA instead of RGB in your screenshot.  Confirmed that's the case on my system too.  That's odd.

If there is an accessibility difference between these two, I would think Chromium would have a slight edge here.

@23 pkasting, I apologise if my comment was confusing, I meant the trend towards higher PPI displays. Displays resolutions have always been increasing, and the increase in display area has not kept up, hence the increase in PPI over time. This is the problem with decreasing font sizes, it heightens the effect of increasing PPI, rather than negating it.

Think also for a moment about the increasing age of internet users where increasing age has a clear correlation with poorer eyesight. So much progress has been made in this area, and by forcing lower font sizes on everyone, you seriously risk eroding these gains.


"Changing the omnibox font size within the UI is orthogonal to the issue of working well on high DPI."

No, it's not, it's not orthagonal to the issue, it's the complete opposite direction. Focusing on making something work well at high PPI/DPI has to include DPI as a fundamental, not exclude it so as to make it go in the opposite direction.

@26: I appreciate your intent to clarify.  That said, I disagree with your argument.

Chrome scales its UI up as DPI increases.  If it did not, then what you are saying would be true: increasing DPI means text becomes physically smaller, and thus less legible, and increasing the font size would be a way to counteract that.

But because we do scale, increasing DPI becomes an orthogonal issue.  There may still be bugs in our scaling or drawing, which are separate issues.  But treating the scaling as a black box that we assume works, the font size is physically the same regardless of monitor DPI.  The decision to make it smaller is separate from the question of what the monitor scale factor is.

Thus we can speak only of the accessibility effects of a certain font size, without considering the issue of DPI.

And in that regard, as I've said before, we do not believe the MD font size represents a fundamental accessibility problem for most users.  We DO believe there are users whose eyesight is very poor, who will struggle to read a font of this size, and our argument is that such users will have similar needs for all other fonts and controls, and thus either will have boosted or should boost the system scale factor to compensate everywhere.

Now, a couple of caveats to that argument:
* Some users use Windows' advanced settings to tweak individual font sizes, which the omnibox is not respectful of.  This is an accessibility issue, and I consider it a bug, albeit one that doesn't hit most people.  It's challenging to fix well.  I believe there's a bug on this, I don't recall off the top of my head.
* The omnibox passively displays URL paths and schemes in a grey font, reducing contrast, making it less legible even though its size may be large.  This is intentional (we're trying to focus users on the critical portion of the URL, the hostname), and we go to full-black during typing so it's easier to actively use the box.  But it still does work to hinder readability, which is part of why a larger base font size than, say, body text is justified.
* In the past, Chrome's DPI scaling has had significant problems (see e.g. comment 2 paragraph 2), which has meant that users are used to things having been more broken than they now are, or have manually worked around us in ways that are now counterproductive.  I'm not aware of any current bugs that rise to that magnitude, but if there are some, the fix for those would be to fix those bugs rather than to work around them by increasing the omnibox font size.

I don't want to close off debate, but this is a bug tracker, and AFAICT, there's nothing we consider a bug happening here.  We made a UI design decision to change the omnibox font size.  We cleared the change with accessibility review, evaluated competitor products to sanity-check whether what we were doing would be out of line, and checked usage statistics after shipping the change to see if there had been any unexpected impacts.  Most negative feedback has been more about preference ("I liked it better before") than function, and I've not yet seen anything that convinces me that the function aspect is a serious problem.

For now, I'll leave this open, in case I'm missing something, but I think the big accessibility issue from MD is the extension badge icons, and I think it would probably be better to focus attention there.

Well, the font sized could be increased without any downsides at all because there is a good amount of unused vertical space in the URL bar, you would not have to change anything other than simply increasing the font size! I could understand the apprehension/resistance if Chrome had to be really modified or the top GUI ended up taking up even more vertical space as a result of the change, but that is NOT the case here.

And for what it's worth, I just got my eyes checked in October, I do not have poor vision and I would prefer the font size in the URL bar be larger on every computer I've tried out. And if there is no downside or compromises in increasing the URL bar font size, I really don't see what there is to debate about.

Unless anyone can think of any downsides or problems that increasing the URL font size would cause...  It seems like an extremely simple change without any downsides.

I am a chrome user and firmly believe this IS a problem. 

There are countless chrome users asking how to make the font size larger.

The font is just on the verge of being too small. It is not comfortable to read.

As noted above, the #1 complaint on Reddit about Chrome 55 was this change. 

> Unless anyone can think of any downsides or problems that increasing
> the URL font size would cause...

There are downsides to larger font sizes.  I don't think these are strong downsides, but they exist.  For example, sometimes I'm searching for more details about something I'm reading on the web page.  A large font / bigger omnibox is more likely to cover the text on the web page I'm trying to read while I type my search.  As another example, as you type in the omnibox, the list of suggestions change.  The larger the omnibox, the more jerky these changes look (more pixels and words are flashing / moving at once).  And yet another example: for people who select omnibox suggestions using a mouse, a larger font size means they'd have to move the mouse more to get the suggestion they want.

That said, I do wonder if there's something going on in particular configurations that make the current font size inappropriately tiny to a small, vocal set of users...

For people for whom the font size is inappropriate, screen shots would help showing the difference between its font and the font on a normal web page (such as this one).

But on every machine I can check now (4 in total) the current omnibox has enough vertical space that you could increase the font size by 1 or 2 without making the box taller/take up more vertical space. There is room in the current omnibox.

I'm looking at some screenshots of what Chrome looked like on my computer before the Material Design makeover and I don't think the URL font should have been as big as it was all those years, so I think the team made the right call making it smaller. But now they made it too small! It was too big and now it's a bit too small. 

@30: While this is tangential to why we changed the size, it's worth responding to this aspect of "but there's plenty of room": remember to consider the union of all target UI languages Chrome supports, not just English (i.e. Latin alphabet).

In e.g. Hindi, fonts of the same character size have far taller ascents + descents than Latin characters.  Users trying to type in mixed Hindi/English text (e.g. for searching) and getting clipped Hindi characters, or characters of wildly different sizes depending on the language, would be poorly served.

More Chrome users are using non-English UI languages than English.

In any case, the important bit here is that we would consider it a bug if the omnibox font was not as big as we intended (see comment 30's request for screenshots to check if the omnibox font is somehow not scaling up properly), and I consider it a bug that that font does not scale up with changes to the system default font sizes, but it's _not_ a bug if the font is as big as intended, the system settings are not being ignored, and people simply want a larger font.

@29: The #1 complaint I saw was extension icon badge font readability, which is absolutely a problem.  Frustratingly, these two unrelated issues keep getting conflated (including by Redditors, some of whom I then followed up with), so it's impossible for me to tell if somehow you're seeing data I didn't, or if you're also conflating them.

I understand. This definitely doesn't qualify as a bug/error. Is there an official place users can make suggestions/requests, like a Chrome uservoice?

Yes; the Chrome product forum is monitored for this type of thing.

Actually, @30, if you look at comment #7, the screenshots posted actually show the new version increased the total omnibox size by a few pixels.  So if you're arguing that making the omnibox bigger will reduce the amount of readable space on the webpage, the Dev team has already done that (Although this is just one set of screenshots from one configuration).  The total top chrome and the omnibox is just slightly taller at 90 pixels in new MD Chrome versus 84 pixels with the non-MD Chrome.  This may be because there is a tad more "whitespace" in the new MD.
However, I will confer that not all of the MD is bad.  The text in the Bookmarks bar and the tabs does look just a bit crisper in MD.
If I may, can I ask that some of the Dev team show us some comparison screenshots of how things look for them?  This whole user base and Dev team not seeing eye-to-eye on this design issue is really frustrating.  I know when it comes to software updates "every change is going to break someone's work flow" (ala XKCD), but I really don't want to be the insolent group that denies change.  From what I've seen so far, visibility really looks like an issue here. 

@35: Your screenshot of Chrome in comment 24 looks exactly as it is intended to look.

@36; OK, that was going to be my next question.  Is the omnibox font tied to a system setting in the Windows Display settings (aside from adjusting the DPI settings)?

No, see the first bullet point in the middle of comment 27.

@Comment 32 

I'm not combining any data. If you look at the very first post in this thread, by Dmazz, they even say the #1 complaint of Chrome 55 was the font size change in the address bar.

I did see comments elsewhere about the extension buttons, and I do agree on that. But once I saw THIS issue was "closed" or "not an issue" I simply had to speak up, because in my view it is an issue. Whether it was the #1 complaint or #2 complaint, clearly the font size change in the address bar IS an issue. It's not just one or two people, there are a bulk of people that see this as a "bug" or a "problem." 

Maybe the flag to revert the material design can be re-instated? Isn't that the optimal solution? It is a win-win for everyone. The people that think the font size is just fine can enjoy it as it is, and people like me who think it's just on the verge of being uncomfortable to read, can turn on a flag to revert back.

@39: It is an issue, but it's not a bug which is the scope of this page.  As said in #36 at least for my setup, the fonts are appearing exactly how they should be.  However, pkasting is still interested in seeing comparison screenshots per comment #30. So you may consider taking some snips of your screen and pasting them together side-by-side in a photo editor and sharing it here so the Devs have a little bit more input to look at.
I'm not sure putting the non-MD theme back in will work out long term as I think they would want to get away from supporting two design themes.  We've already crossed that warning grace period by justing changing the design flag and forgetting about it long ago and not supporting the issue back then.

No, it cannot be reinstated.  Carrying two designs had an enormous effect on code complexity, prevented a variety of bugfixes, and in general was a huge albatross on the code's neck.  (I had to fight to keep both in as long as we did, to make sure we had time to properly triage regressions before removing the old code.)

As to whether this issue is significant, we're not really getting anywhere going around on that.  I respect that a number of people would prefer the old size, but that alone is not sufficient to reverse this design decision (literally every change we have ever made has resulted in a number of people who preferred the old way).

I'm going to briefly restate the end of comment 27, but a bit more bluntly: no one is sharing new data that would cause this decision to be reconsidered.  "I consider this a bug" is not new data.  "Lots of people on Reddit said they didn't like this" is not new data.  Respectfully, please let this one lie unless there is something truly new to bring in.

@40  Pkasting seems intent on just keeping this issue closed. Should I still provide screenshots?  If I should, (and it will be considered this is is a problem) I can do that tomorrow. And, if this isn't the place to voice my displeasure of this change, where is? 

@41 II don't understand why you want to "let this one lie" if plenty of people are telling you this change isn't working for them. You told me I was conflating data, so I was merely pointing out this was seen as an important issue. That's what I'm bringing to you. I'm trying to communicate that this is a very unwelcome change.

This isn't like "Oh, you changed the color of the logo. I want the original colors back!"  It is a change that affects my work.

I'm not trying to be difficult. I just see this as a problem. And to see that it isn't really seen as one, is very frustrating to me.

I think what they are saying is that this is not a bug. We should all go to the official google Chrome product forum and ask Google to make the url font bigger and hope they don't ignore/dismiss us. Sadly, that's all we can really do.

Here are my screenshots. The top is the old design, the bottom is the new design. I think the top text is much easier to read. Looking at the shots like that, perhaps the font doesn't need to be that large, but clearly there was a big reduction in size. It doesn't need to be that drastic. 

Deleted: address bar.jpg 106 KB

	address bar.jpg 106 KB View Download

I think what comment 30 was hoping for was more "a screenshot of the context of the omnibox font against the web content area text and other system text that you normally work with".  The hope is that the omnibox font is at least as large.

Remember that the omnibox is an input-focused control in most cases, not a display-focused one -- URLs tend to be opaque pieces of data that only occasionally have useful data for most users, so as long as the control is at least as readable as typical web/system content, we feel like we're doing OK.

So just to confirm, you would have to extend the height of the URL bar if you wanted to increase the font size? 

I don't know.  I assume you're responding to comment 32.  My intent with that comment was merely to say, don't judge available space by Latin characters only.  As to whether we still have available space after taking into account all languages, it would take more work to find out.  We do have design reasons for wanting whitespace around things too.

The boundary here is: we're interested in collecting data on accessibility problems.  We're not planning to re-litigate the other design considerations that went into making this change.  Attempting to do so will just result in locking the bug.

something just occurred to me and I'm surprised no one has mentioned it yet: the "Touch" (formerly known as "Hybrid") version of Material Design has a taller URL bar than "Normal" Material Design, yet the font size remains the same even though there is without a doubt enough free vertical space to increase the font size. Surely, in the case of the "Touch" version of Material Design the URL font size can be increased slightly? 

(go to "UI Layout for the browser's top chrome" in flags and switch it to "Touch") 

While I don't think you're trying to derail things, you don't seem to be getting my message.

Outside of accessibility concerns, issues with respecting system settings, and flat-out bugs, the omnibox font size is not going to be increased, regardless of UI mode, available space, etc.  I could spend more time explaining why increasing the size just for hybrid mode is not a good idea, but the more important thing is that I set a boundary, and that boundary was not respected, and I am closing this bug to further comments as a result.