Refresh: omnibox text moves when you start typing |
||||||||||||||||||||||||||||||||||
Issue descriptionReproduced on both Windows 10 and Linux. If you open a new tab and type in the omnibox, the start of the text jumps to the right from its initial position. It's easier to see if you do the following: 1. Focus the omnibox and type something (for example, "blah") in it 2. Unfocus the omnibox 3. Focus the omnibox again, but click on the end or press the right arrow so that the text isn't selected 4. Begin typing The "blah" that was already there will move to the right. I thought this was intentional at first, but it does look a bit odd. I attached some screenshots as well. tommycli@, can you investigate or confirm that this is intentional?
,
Jun 15 2018
Oh -- that movement. Indeed that is intentional. The intent is to make the input text line up with the suggestions text as the user is typing. Sorry for the confusion bsep. -- By the way - I noticed that in the first picture, the background of the input field differs from the rounded frame in general. I've seen that intermittently but it's a bug. If you have a series of steps to reproduce that reliably, please let me know. Thanks!
,
Jun 15 2018
Hmm, looks like I can get it consistently, on Windows 10 at least. 1. Type something in the omnibox 2. Unfocus it 3. Click on it again (don't use a keyboard shortcut like Alt+D or F6, that seems to not trigger it) I can file another bug, if you'd like.
,
Jun 15 2018
bsep - Sure, that would be great! It seems more intermittent on Linux, so I will definitely debug this on Windows if it's more reliably reproing there.
,
Jun 18 2018
Issue 853461 has been merged into this issue.
,
Jun 18 2018
Working as intended. We do intend the text to shift depending on whether or not the popup is open. This is actually the second bug I've had filed on the shifting text. I'll send this to bklman to comment.
,
Jun 18 2018
I'm repoening, because this is a regression of something we've taken great care with over the years. To ensure the text in the omnibox doesn't move when the popup opens, we've always ensured the icon/padding sizing/positioning in the closed state matches what we want to do in the dropdown. That way there's no need for movement. I'd like us to find a way to maintain this design attribute, as having the text shift on typing distracts the user at a critical moment and increases the cognitive burden of using the omnibox, so we'd really like to avoid this. I'm happy to try to help resolve any design or technical concerns blocking fixing this :)
,
Jun 18 2018
Okay - this issue is also now blocking 852828, as we won't be able to resolve that until we finalize our design direction.
,
Jun 18 2018
Tommy asked me to share my idea for a route forward. I suspect the issue here is as follows: 1) Ideally we'd like all dropdown rows to align their text. 2) Rich suggestion icons are bigger than the existing icons. 3) To allow for (2) while maintaining (1), we increased the padding for the small-icon case, in the dropdown only. 4) Because this padding looks too big with only small icons, we didn't do it in the non-editing case for the omnibox. If this is correct, I think item (4) is a hint that we're making the wrong call: the padding looks too big to me on all dropdown rows without rich suggestions, which is most rows. Instead, I would sacrifice (1) above: leave the padding as it was and have all dropdown rows and the steady-state and typing omnibox all align, except that for rich suggestions, the text starts 16 DIP (or whatever) right of the other rows. This achieves the goals stated in comment 7 and maximizes the visual appeal of the common case. It makes rich suggestions stand out more, but we arguably want that (which is why we're increasing their icon size). It makes it slower for the eye to scan past such a suggestion's row, but again, we arguably want that. (If we don't, we should either use smaller rich suggestion icon, or scale up all the icons to match, which has its own problems).
,
Jun 18 2018
Not sure if this could be an option, but maybe the old friend "divider" could help here also a little bit as suggested in issue 853461 ? (Please see the attached screenshot.)
,
Jun 18 2018
mehmet: Thanks! That's also an interesting idea - thanks for sharing. I've linked the bug to our designer and we will post here once we figure out how to proceed.
,
Jun 18 2018
Looping in Justin and Emily here in case they have some input on this design feedback.
,
Jun 18 2018
Personally, the text shifting on popup-open seemed fine to me and I barely noticed.
,
Jun 18 2018
For the record, I didn't notice either until I had to investigate a relevant test failure. But when I did notice, it seemed like a bug.
,
Jun 18 2018
,
Jun 22 2018
Following up from the UX/UI side. This jog in the text is related to detailed iteration and the overall layout grid of the suggestions we are adding in M69. Our goal is to have all icons and text strings aligned from the omnibox NTP, resolved URL, and raised states. We are finalizing some of these changes and confident we can eliminate this jog, but don't want to make any changes until we have a resolution on some other details. Ill make sure to let tommycli@ know where we land on this.
,
Jun 22 2018
Cool -- make sure to include the security chip text in your design (if there is text like "Secure", it should appear at the same position the omnibox text would normally appear in if there were no security chip).
,
Jun 22 2018
Thanks PK. Im not sure if we will address the "Secure" text since we have plans to remove it soon as well...so our end result would be aligned with just secure icon and url. Ill double check with emilyschechter@ on when we plan to ship ths.
,
Jun 22 2018
Even if we remove "Secure" there's still text there in some cases ("Not secure" for HTTP), so the constraints would still be the same.
,
Jun 22 2018
Not sure, if this will be still relevant, but I noticed that the URL text is currently 2px to far right. So the Lock icon is not perfectly centered between Omnibox border and URL text. You can notice it, when you hover over the lock icon or compare the URL text agains the position of the Secure text.
,
Jun 22 2018
Ive seen this too. I haven't finalized my audit of this since this overall inset is related to the size we end up deciding for rich-suggestions. Once we know what that number is, we can make these adjustments. pkastings@ Ill be sure to add the not secure states to my redlines to make sure we are considering all scenarios.
,
Jun 25 2018
Triage: Upgrading to P1 - Flicker or movement now meets the P1 bar.
,
Jun 28 2018
We had some churn on the UI-review side and have been addressing all the feedback given from out Dogfood. Attached is the summary of the landed spacing. Im dropping this now so tommycli@ can get after this work, and will be updating the rest of my redlines this week. Summary of changes: 1. We are embracing the "text jog". This is a known compromise in order to have a tighter steady state lockup of the secure icon and URL. 2. We are working with helenepark@ to see how motion can make this transition of states smoother and more natural 3. Core metric change (see attachment): – Steady state: Margin btwn icon + URL: 8dp – Raised state: Margin btwn icon + Title/URL: 20dp – Raised state: Entity images stay at 32dp (with 12dp margin)...correct in Canary today
,
Jun 28 2018
Triage: moving to eng from ux
,
Jun 28 2018
Can the spec be expanded to explicitly cover the case of "Secure" and similar text appearing? I'm pretty sure the current behavior in that case isn't quite what you want even if you stick with text jog.
,
Jun 29 2018
> 2. We are working with helenepark@ to see how motion can make this transition of states smoother and more natural Safari on macOS has a nice animation when focussing the Location Bar. Maybe the same animation can be used here for the short move of the text in the Omnibox? Attached a screencast. Thanks.
,
Jun 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/de2713606a233481a4ad5ffb469e1af0b5a7805f commit de2713606a233481a4ad5ffb469e1af0b5a7805f Author: Tommy C. Li <tommycli@chromium.org> Date: Fri Jun 29 18:05:29 2018 Omnibox UI Refresh: Animate the text jog when suggestion popup opens. Many devs have complained that the text moves unexpectedly when the popup opens. After consulting with UX, we are embracing the text jogging to make it line up with the suggestions text. This CL adds an animation to slide the text over, making the text jog hopefully less jarring. Bug: 853355 Change-Id: If272e4076e30c967c0211c988e5e9f10300366bf Reviewed-on: https://chromium-review.googlesource.com/1119400 Commit-Queue: Tommy Li <tommycli@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Reviewed-by: Justin Donnelly <jdonnelly@chromium.org> Cr-Commit-Position: refs/heads/master@{#571544} [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/harmony/chrome_layout_provider.cc [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/harmony/chrome_layout_provider.h [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/location_bar/location_bar_view.cc [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/location_bar/location_bar_view.h [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/omnibox/omnibox_view_views.cc [modify] https://crrev.com/de2713606a233481a4ad5ffb469e1af0b5a7805f/chrome/browser/ui/views/omnibox/omnibox_view_views.h
,
Jul 2
I agree that the movement still feels bad. Note, however, that I suggested Tommy use a long animation time in order to make the movement feel deliberate. In practice, however, it's clear that that time is too long as the animation continues while you're typing, which is weird. I'll try a few other animation timings today to see if there's something that feels better. Suggestions welcome.
,
Jul 2
One more problem is, that the move back animation (after pressing the Return-Key), does not always appear. Example 1: - open a new window and type in "Browser" and press enter, so that you are navigating to the Google Search Page. You will notice, that the move back animation does't appear. (Screencast 1) Example 2: - open a new window and type in "apple.com" and press enter, so that you are navigating to the www.apple.com. You will notice, that the text moves back and then the Apple-Security-Chip appears, but both also without animation. (Screencast 2). So we have a mix of animation and no animation which is weird, too.
,
Jul 2
Since we're fine with the current text positioning in the autocomplete popup, what prevents us from applying the same positioning to the input box? After typing going through the few omnibox suggestions, it does seem like the small non-rich case is the common case. Optimizing for that would be a reasonable course of action. Personally, I'm finding the text animation to be super distracting as I use the omnibox.
,
Jul 2
,
Jul 2
#32: Making the positioning the same in the steady-state input is the other course of action we're considering. The problem there is that the spacing looks too large in that case. We're trying to find a path that allows for more space in the suggestions list but less in the steady-state display. I'm going to send out a change to 60 ms. This feels much better to me. Though I'm not sure we can solve the general feeling of unpleasantness of the text insertion point moving without a lot more work +bklmn who's been working with bettes on this.
,
Jul 2
I think it's also still worth considering going back to the original design, where the spacing was small but for all cases except rich entities. But just to be clear, we're still experimenting here. Keep sending in feedback on what feels good or bad.
,
Jul 2
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e4847026f894f1471ca475048a76a8fcfee2948a commit e4847026f894f1471ca475048a76a8fcfee2948a Author: Justin Donnelly <jdonnelly@google.com> Date: Mon Jul 02 23:36:40 2018 [omnibox] Reduce the animation time for changing the text layout. I'm not sure this really solves the problem of the changing layout feeling weird, but it mitigates the issue while we continue to try things out. Bug: 853355 Change-Id: Ia40f49e4f4974ddee9e036d5bfeb3340bedd7c0d Reviewed-on: https://chromium-review.googlesource.com/1123336 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Justin Donnelly <jdonnelly@chromium.org> Cr-Commit-Position: refs/heads/master@{#572042} [modify] https://crrev.com/e4847026f894f1471ca475048a76a8fcfee2948a/chrome/browser/ui/views/location_bar/location_bar_view.cc
,
Jul 3
This behavior feels yet slightly odder in the zero suggest case: https://crbug.com/859540 .
,
Jul 3
Hi, I tried latest Snapshot #572197 (but I think the patch from c#36 is also already in latest Canary). Yes, the animation is quicker now, but the movement at all feels still wrong and disturbing. Maybe we can test a few days, how it feels with the larger space? Maybe is is okay and the too large space doesn't disturb? And what about a divider as suggested in C#10? It would be placed centered nicely between lock and text and the too large space wouldn't be longer there. Since the about:pages, Tab-to-Search and the Secure Chip also uses dividers, this wouldn't feel wrong. WDYT? Thanks :)
,
Jul 9
Issue 859633 has been merged into this issue.
,
Jul 11
FYI I'm meeting with emilyschecter, bklmn and bettes today to discuss this issue.
,
Jul 12
,
Jul 12
,
Jul 12
Update: We're tentatively going to try the separator as shown in #10 (thanks for the mock, mehmet). Assuming it sticks, that means there will be no movement when transitioning between the steady state and suggest state (except when there's text in the security chip, as today).
,
Jul 12
I like that solution.
,
Jul 12
+1
,
Jul 12
Cool, thank you in advance :) I'm assuming that the divider will be hidden then in the suggest state - that would be great too :)
,
Jul 12
mehmet: yes, that's correct.
,
Jul 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d1cd2917267186edc104c074833e8d382727cb67 commit d1cd2917267186edc104c074833e8d382727cb67 Author: Justin Donnelly <jdonnelly@google.com> Date: Fri Jul 13 14:16:33 2018 [omnibox] Remove text movement animation. This animation was added as a way of making the movement that happens when omnibox suggestions are shown less jarring/annoying. It actually had the opposite effect. ¯\_(ツ)_/¯ This change is in preparation for a follow-on CL which will remove the movement entirely. Bug: 853355 Change-Id: I7ae000f67fd09f3dde7a1583568696c700d19622 Reviewed-on: https://chromium-review.googlesource.com/1135774 Reviewed-by: Kevin Bailey <krb@chromium.org> Commit-Queue: Justin Donnelly <jdonnelly@chromium.org> Cr-Commit-Position: refs/heads/master@{#574906} [modify] https://crrev.com/d1cd2917267186edc104c074833e8d382727cb67/chrome/browser/ui/views/location_bar/location_bar_view.cc [modify] https://crrev.com/d1cd2917267186edc104c074833e8d382727cb67/chrome/browser/ui/views/location_bar/location_bar_view.h
,
Jul 15
WIP CL: https://crrev.com/c/1136493 Screenshots attached. Intent is to match the redlines here: https://docs.google.com/presentation/d/19iJr9nglo4BhgE6Y_eNqCJH09GTXZkPxRPT6x_2AdGY/edit#slide=id.g3d81441120_0_16
,
Jul 15
re#49: Thanks 👍 I am looking forward to test it soon :)
,
Jul 16
Thanks Justin. Also, can we make the pipe divider 12dp tall, instead of 16dp?
,
Jul 16
@51: Are you sure? When I mocked that locally, it started looking more like some sort of glitch, like a letter (an 'l' or something) or part of an icon. I don't know exactly why it felt like this. My hypothesis is that the divider between tabs is currently 20 DIP, so while 16 doesn't match it, it feels a little more like "oh, this is another divider of things" rather than some unique creature that I don't understand. Note that we also have a similar divider in other places in the UI, e.g. in the bookmarks bar before "other bookmarks", so if you still think changing is the right course, you might want to give guidance about changing the other cases like that one.
,
Jul 18
bklmn: Are you saying you want the divider to be a different height than when there's text (e.g. "Not Secure")? It's 16dp tall in the screenshots above because I'm using the same divider code as in the text-present case. Or are you saying you want to change to 12dp in both cases?
,
Jul 18
Yeah the proposal question if a 12dp divider fits better with the lock and URL size (would change in both cases). We already have 2 different size divider based on the surrounding elements, and 12 felt a bit more appropriate and less distracting given it will present always (see attachment). If we are concerned about the 12dp deviating from the 16dp in the "trusted" space, do we think we could do 12dp for both dividers? My vote is for 12dp, but leave this coreUI detail to +bettes.
,
Jul 18
Talked with +bettes offline. We are keeping it at 16dp. Sorry for the runaround.
,
Jul 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/076efaa47e49bb08647a1ef84dd29441f4dfed4e commit 076efaa47e49bb08647a1ef84dd29441f4dfed4e Author: Justin Donnelly <jdonnelly@google.com> Date: Wed Jul 18 23:38:16 2018 [omnibox] Change divider in the location icon view from 1px to 1 DIP. This eliminates the need for special layout in the > 1 display scale case. Bug: 853355 Change-Id: I5c4a30cee3b8ad05bed1bad094678351ec728ea5 Reviewed-on: https://chromium-review.googlesource.com/1142440 Commit-Queue: Justin Donnelly <jdonnelly@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#576252} [modify] https://crrev.com/076efaa47e49bb08647a1ef84dd29441f4dfed4e/chrome/browser/ui/views/location_bar/icon_label_bubble_view.cc [modify] https://crrev.com/076efaa47e49bb08647a1ef84dd29441f4dfed4e/chrome/browser/ui/views/location_bar/icon_label_bubble_view.h
,
Jul 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73bedbe3eb580a0ba21617a208546f03212dc7f1 commit 73bedbe3eb580a0ba21617a208546f03212dc7f1 Author: Justin Donnelly <jdonnelly@google.com> Date: Thu Jul 19 02:10:10 2018 [omnibox] Remove text movement in Refresh when opening suggestions. This involves several small changes: - Adjust the layout of IconLabelBubbleView to account for the case where we want to show the separator but not the label. - Move the extra space shown in suggest mode from LocationBarView to IconLabelBubbleView so it can use the logic and spacing values there. - Add LocationIconView::ShouldShowSeparator() to indicate that we want to show the separator in the steady-state case. - Adjust the spacing in the suggestion result view to match the current spec. Also, remove a bit of dead code: GetMaxSizeForLabelWidth() and GetOuterPadding() in IconLabelBubbleView. Bug: 853355 Change-Id: I108dbf80de3c060ca56bbe502101dfbb1123ef4e Reviewed-on: https://chromium-review.googlesource.com/1136493 Commit-Queue: Justin Donnelly <jdonnelly@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#576325} [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/location_bar/icon_label_bubble_view.cc [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/location_bar/icon_label_bubble_view.h [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/location_bar/location_bar_view.cc [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/location_bar/location_icon_view.cc [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/location_bar/location_icon_view.h [modify] https://crrev.com/73bedbe3eb580a0ba21617a208546f03212dc7f1/chrome/browser/ui/views/omnibox/omnibox_match_cell_view.cc
,
Jul 19
The UI with the divider as shown in the screenshots in #49 should be in tomorrow's Canary.
,
Jul 19
Leaving this open while we evaluate how well the divider solution works in practice. Lowering the priority in the meantime.
,
Jul 19
Looks like I missed the cutoff for today's Canary build. Should be there tomorrow.
,
Jul 19
I'm testing it in latest Chromium Snapshot atm :)
,
Jul 20
,
Jul 24
Joel, Alex and myself discussed the pipe divider last week and decided that there should be no pipe. So there will be an immediate jog with no animation (aka proposal 1 from the original UI review deck). https://docs.google.com/presentation/d/19iJr9nglo4BhgE6Y_eNqCJH09GTXZkPxRPT6x_2AdGY/edit#slide=id.g21b5d52390708a4_3 --- There are 3 main principles that we're evaluating this against: 1) all dropdown rows need to align their text Equal padding for dropdown rows and rich entities is preferable from an aesthetic and scannability perspective. Rich entities may not be as common, but we're anticipating simultaneous rich entities at once, so variable padding isn't preferable or really functional – especially as the feature gains more awareness and adoption. 2) rich suggestion icons need to be 32dp to ensure legibility and effectiveness Rich entities are simply not perceivable <32dp so we need to ensure clarity for them to be useful 3) no pipe is the preferred "face" of Chrome With the removal of the 'secure' string (and the neutral lock icon), we have the opportunity to bring a simple and clean "face" to Chrome. We understand the concerns around shifting text while typing, but there's a higher benefit placed on #3 that outweighs what we perceive to be an indistinct characteristic of the omnibox.
,
Jul 27
We've made the change to return to the text jog, which should appear in the next Canary. However, we also introduced a flag to restore the pipe behavior so we can continue to collect feedback on the two approaches.
,
Aug 22
,
Sep 7
Issue 879843 has been merged into this issue.
,
Sep 7
FWIW, the jog really bothers me. Not sure if this has been considered, but I would probably be happy with an invisible divider, i.e., the cursor doesn't move but there's no visible pipe.
,
Sep 18
,
Sep 20
,
Sep 26
|
||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||
Comment 1 by bsep@chromium.org
, Jun 15 2018