<sl-select required> alignment issue after a validation failure

[elidupuis]

I think I've found a small layout bug in sl-select, specifically after a form validation fails on the field. This is reproducible on the Form Controls documentation page.

In the screenshots below I've highlighted the flex layout for part="combobox" in DevTools.

Without a failed validation

After a failed validation

Steps to Reproduce

1. Fill in the name field (so that it's valid).
2. Attempt to submit the form.
   The sl-select field shows the default required field browser UI.
3. Choose a Favorite Animal in the sl-select
4. Notice the alignment bug in the combobox part.

From what I can tell this is related to the padding-inline declaration on the combobox but I'm not sure why it's being affected by the validation failure—the style appears to remain var(--sl-input-spacing-medium) in all cases.

[isaacag]

I was able to reproduce the behavior above.

[claviska]

I noticed this a few weeks ago, but it seemed to go away after a Chrome update. I can't seem to replicate it anymore, and when I checked Safari and Firefox, neither exhibited this behavior.

My current Chrome version is: 109.0.5414.119 (Official Build) (arm64)

May I ask what versions are you folks testing this on?

[claviska]

Tip: type about:version into the address bar and click the copy button to the right of the version.

[isaacag]

Chrome 109.0.5414.120, Edge 110.0.1587.41

[elidupuis]

I can't replicate in Firefox or Safari either. My Chrome updated overnight; yesterday I was on 109, today 110 and I can still replicate.

Chrome 110.0.5481.96 (Official Build) (x86_64) 
Edge 110.0.1587.41 (Official build) (x86_64) 

[claviska]

Can anyone provide a quick step-by-step? I tried again but I can't replicate it in Chrome.

When I first noticed it, I tried changing the container's display property in the web inspector. Oddly enough, reverting it back to its original value after changing it "fixed" the position, so it definitely seemed like a rendering bug in the browser.

In order to report it, I'll need a minimal test case which means I need to be able to repro it in Shoelace first. If anyone can provide the steps or even a minimal test case in CodePen or similar, we can get it reported upstream. For whatever reason, I can't break it now.

[elidupuis]

@claviska I create a minimal CodePen to show the issue in isolation: https://codepen.io/elidupuis/pen/YzOXqPg.

In the CodePen, I'm calling reportValidity() automatically so that as soon as you choose an option in the sl-select element the layout bug is triggered.

Most notably:

• There's no issue before reportValidity is called or if the element doesn't have the required attribute.
• The issue occurs:
  • after calling reportValidity() on the sl-select element.
  • after submitting the form without choosing an option in the sl-select element.
• The issue resolves itself after toggling the padding-inline declaration in DevTools (on the part="combobox" element).

I also did a quick screen recording to show the flow I'm using to replicate.

• Full resolution: https://drive.google.com/file/d/1Bqiifjsxzi7-bkVgTOR9OB39rkKBwdoX/view?usp=sharing
• Low resolution (GH only allows 10MB uploads): https://user-images.githubusercontent.com/196410/219492194-cd634478-b843-4dbc-a844-c7d812f3e091.mov

Is this enough to go off of? Let me know if you're still having trouble replicating the issue.

[claviska]

I was finally able to reproduce this again thanks to @elidupuis' example. While I still can't explain exactly why it happened, adding a top and left position to the hidden .select__value-input stops it from occurring. It seems to have something to do with the absolutely-positioned element's implicit position. Setting both properties fixed it.

See f79a670 for details.

[elidupuis]

Amazing, thanks @claviska! 🙌