Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: sbb-autocomplete first element always selected and change only with arrow events #275

Open
daniele92vp opened this issue Feb 12, 2020 · 6 comments
Labels
bug Something isn't working comp: lean Issues related to @sbb-esta/angular lean design comp: standard Issues related to @sbb-esta/angular standard design effort1: hours prio3: medium Should be done when time available ux feedback

Comments

@daniele92vp
Copy link
Contributor

Describe the bug
When using autoActiveFirstOption set to be true, the first element will be always highlighted in red. When hovering with the mouse on the other results, there are always 2 suggestions highlighted, the very first one and the one on which the mouse in on.

At the moment the expected behavior (option in red color) works only when using the keyboard arrows to change selected element from the list.

Should change also when hover-mouse event is triggered.

To Reproduce
Steps to reproduce the behavior:

  1. Use the component <sbb-autocomplete [autoActiveFirstOption]="true">
  2. Start to write until the function to show suggested result is triggered
  3. Hover with mouse on the second or other results
  4. The first result will be always red-highlighted

Expected behavior
Should be only one result red-highlighted when hover with mouse

Screenshots
autocomplete-error

@daniele92vp daniele92vp added the bug Something isn't working label Feb 12, 2020
@jeripeierSBB jeripeierSBB added comp: lean Issues related to @sbb-esta/angular lean design comp: standard Issues related to @sbb-esta/angular standard design effort1: hours prio4: low Should be done after all higher priorities are done labels Feb 12, 2020
@jeripeierSBB
Copy link
Collaborator

I think the mentioned behavior is on purpose. Mouseover doesn't set a dropdown entry as active, so the first option is still the active one. The styles of hover and active are just the same. @mikemorgenthaler @Frenggi what's your opinion?

@Frenggi
Copy link

Frenggi commented Feb 18, 2020

For me, the current behaviour is correct to follow the design. BUT: I think the design is not correct. We should differentiate between hover and active states. The used pattern is: red for hover, black for active, e.g. processflow. What do you think @mikemorgenthaler ?

@mikemorgenthaler
Copy link

I'm agree with you @Frenggi. There is a strange behaviour with the hover effect on sbb.ch as well. Everywhere else on hover we use the dark red. So yes, let's accept the Bug and define a solution.

@daniel-sc
Copy link
Contributor

daniel-sc commented Aug 18, 2021

Hi @jeripeierSBB @kyubisation
could you please fix this, now that the styling bug is resolved?

@kyubisation kyubisation added prio3: medium Should be done when time available and removed prio4: low Should be done after all higher priorities are done labels Aug 27, 2021
@jeripeierSBB
Copy link
Collaborator

Hi @daniel-sc
This issue is still not resolved by UX, so we have to wait until they provide a solution.

@mhaertwig
Copy link
Collaborator

@mcilurzo can you please have a look at this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working comp: lean Issues related to @sbb-esta/angular lean design comp: standard Issues related to @sbb-esta/angular standard design effort1: hours prio3: medium Should be done when time available ux feedback
Projects
None yet
Development

No branches or pull requests

7 participants