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

Examples/Floating-labels: fix bad behavior with autofill #31948

Closed
wants to merge 1,711 commits into from
Closed

Examples/Floating-labels: fix bad behavior with autofill #31948

wants to merge 1,711 commits into from

Conversation

eduardogoncalves
Copy link

If the browser has already credentials on the autocomplete, the layout of will breaks.

image

patrickhlauke and others added 30 commits July 10, 2020 16:00
* clear timeout before showing the toast

* Add unit test

* Remove the check for timeout

* Check for clearTimeout to have been called

Co-authored-by: XhmikosR <xhmikosr@gmail.com>
Replaces #30498 by adding four new null default variables for .nav-link. Doesn't carry over font-style from the original PR though since that's rarely used, at least by default Bootstrap. Nullifies all values from that PR, too, since we count on some basic inheritance here and don't need color by default.
* Expand on disabled fieldsets and faked buttons

include further advice/information on how to disable faked buttons for keyboard/AT users

* Centralise accessible name advice in forms overview

seems odd to only mention (separately) label, aria-label etc in input-group and layout. the advice is just as pertinent in other sections like select. checks only skims over this.

moving this, in expanded form, into the overview section itself. adding a specific cross-reference (just because they are easily left with no accname at all) in the checks page.

* Change warning about accessibility, modify server-side example

- paradoxically, due to our current problems with validation (see #28414) and the fact that browsers seem to have improved in this area for the most part, it's now actually better to use browser-native validation
- added explicit `id` and `aria-describedby` association to at least the server-side form error messages, to show how it should be done properly, and expanded the prose for that explaining this.

* Replace `.sr-only` with `.visually-hidden` in new addition

* Copy edits for clarity in parenthetical

* Copy and formatting tweaks

- Wordsmithing here and there
- Turns some hyphens into em dashes
- Turns a long running comma separated list into an unordered list
- Rearranges some copy just a bit

Co-authored-by: Mark Otto <markd.otto@gmail.com>
* feat(buttons): easier disabled state customization

* docs(migration): mention new arguments for disabled state in button-variant()

* Update migration.md

Co-authored-by: XhmikosR <xhmikosr@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Tweak green and cyan colors, bump min contrast ratio to 4.5

Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* @rollup/plugin-babel          ^5.0.4  →   ^5.1.0
* @rollup/plugin-commonjs      ^13.0.0  →  ^13.0.1
* @rollup/plugin-node-resolve   ^8.1.0  →   ^8.4.0
* autoprefixer                  ^9.8.4  →   ^9.8.5
* hugo-bin                     ^0.61.0  →  ^0.62.0
* rollup                       ^2.20.0  →  ^2.21.0
* Clarify screen reader changes

* Add some docs and reboot notes to migration guide

* Add mention of docs renaming of screen reader helper page

* Mention null vars from navs PR at #31035

* Update migration.md

Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
Version.md on v5.getbootstrap.com is only referring to v1 > v4 when it should be referring to v1 > v5.
Bumps [hugo-bin](https://github.com/fenneclab/hugo-bin) from 0.62.0 to 0.62.1.
- [Release notes](https://github.com/fenneclab/hugo-bin/releases)
- [Commits](fenneclab/hugo-bin@v0.62.0...v0.62.1)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [@rollup/plugin-commonjs](https://github.com/rollup/plugins) from 13.0.1 to 14.0.0.
- [Release notes](https://github.com/rollup/plugins/releases)
- [Commits](rollup/plugins@commonjs-v13.0.1...commonjs-v14.0.0)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
New default behavior for scroll anchoring (rolled out in Chrome 84?) leads to unsightly/odd accordion interactions - see #31341
This rule suppresses this new behavior and reverts back to the old way.

See https://drafts.csswg.org/css-scroll-anchoring/
Bumps [eslint](https://github.com/eslint/eslint) from 7.4.0 to 7.5.0.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Changelog](https://github.com/eslint/eslint/blob/master/CHANGELOG.md)
- [Commits](eslint/eslint@v7.4.0...v7.5.0)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
XhmikosR and others added 6 commits October 19, 2020 16:05
For some weird reason, using "Exports" as the callout header leads to TypeError coming from clipboard.js
Bumps [nodemon](https://github.com/remy/nodemon) from 2.0.5 to 2.0.6.
- [Release notes](https://github.com/remy/nodemon/releases)
- [Commits](remy/nodemon@v2.0.5...v2.0.6)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
@eduardogoncalves eduardogoncalves requested a review from a team as a code owner October 21, 2020 21:27
@eduardogoncalves eduardogoncalves changed the title fix bad behavior with autofill Examples/Floating-labels: fix bad behavior with autofill Oct 21, 2020
@@ -76,7 +76,8 @@ body {
color: #777;
}

.form-label-group input:not(:placeholder-shown) ~ label {
.form-label-group input:not(:placeholder-shown) ~ label,
.form-label-group input:-webkit-autofill ~ label {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since :-webkit-autofill isn't supported in all our supported browsers (Firefox and Edge 16 <> 79), this selector invalidates the whole declaration block for some of them.

There's an internal pseudo-class in Firefox (:-moz-auto-fill) but it doesn't seem to be available for authors as of now.

So in order to apply this as a progressive enhancement, we need to dedupe those selectors (and duplicate the rules).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the current autoprefixer version support this property? I haven't tried it yet.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @XhmikosR, where can I learn on how to check this info?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

postcss/autoprefixer#626 is outdated by a few years, unsure if there's anything else for it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that Firefox doesn't have this bug in the first place, so autoprefixing may not be an issue here (for now anyway, unless it turns out Chrome are doing this on purpose as a security measure, and Firefox later copies the behavior)

Duplicated the rule to `input:-webkit-autofill` to prevent the invalidation of the whole declaration block as pointed by @ffoodd
@mdo
Copy link
Member

mdo commented Oct 22, 2020

Is this nullified by #30449?

@eduardogoncalves
Copy link
Author

eduardogoncalves commented Oct 22, 2020

Hello @mdo, this issue is still present in #30449. The issue appears when browser autofill the field.

image

@MartijnCuppens
Copy link
Member

@eduardogoncalves, what version of Chrome is that? I can't reproduce this on v86 (mac & windows)

@eduardogoncalves
Copy link
Author

Hi @MartijnCuppens it's version 86.0.4240.111 running on Windows 10 Pro 2004 19041.572

image

@eduardogoncalves
Copy link
Author

eduardogoncalves commented Oct 23, 2020

I made a video to demonstrate it, because if you click in any part of the screen, it 'fixes' the issue. But if you just scroll the page, you can see the issue. This means that if the field is in the first viewport, the user will see the issue on chrome.

The video was rec in Windows
https://youtu.be/FUoBUuhYJDY

The issue on chrome v86 mac
image

@patrickhlauke
Copy link
Member

are you running some form of autofill extension or similar? can't replicate the behavior, at least not on the https://deploy-preview-30449--twbs-bootstrap.netlify.app/docs/5.0/forms/floating-labels/ page

@eduardogoncalves
Copy link
Author

@patrickhlauke I'm using chrome's default credential manager.
image

To make it work, I typed some text into email and password input, and asked the browser to remember that info.
image

@patrickhlauke
Copy link
Member

ah, hadn't tried explicitly saving the data once typed in (i usually rely on chrome saving credentials on an actual submit). ok, i can see the issue now. it does look like a bug in Chrome

@patrickhlauke
Copy link
Member

patrickhlauke commented Oct 23, 2020

indeed, just tried a rough minimal test case, and chrome has a bug there where it doesn't evaluate the :placeholder-shown until the first interaction/click on the page (maybe for security reasons?)

https://codepen.io/patrickhlauke/pen/gOMgLxR / https://cdpn.io/patrickhlauke/debug/gOMgLxR

[edit: chrome bug filed https://bugs.chromium.org/p/chromium/issues/detail?id=1141874 ]

@eduardogoncalves
Copy link
Author

Adding style rules to input:-webkit-autofill seems to prevent this from happen.

@mdo
Copy link
Member

mdo commented Oct 25, 2020

This will need to be retargeted to v4-dev I think, and then applied to the floating labels PR at #30449. Any interest in handling that @eduardogoncalves?

@eduardogoncalves
Copy link
Author

eduardogoncalves commented Oct 26, 2020

[edit] just saw that you're editing it.

@mdo, ok, I can do it. Do you mean edit _floating-labels.scss in v5-floating-labels branch?
https://github.com/twbs/bootstrap/blob/v5-floating-labels/scss/forms/_floating-labels.scss

@mdo
Copy link
Member

mdo commented Oct 26, 2020

@eduardogoncalves Hah, yeah, testing it out for v5 in that PR. Would you mind doing this PR for v4-dev though? We can fix this issue for v4 users that way. You might be able to retarget this PR to v4-dev, but unsure if there are any major differences between the example in v5 vs v4.

@eduardogoncalves eduardogoncalves changed the base branch from main to v4-dev October 26, 2020 23:43
@eduardogoncalves eduardogoncalves requested a review from a team as a code owner October 26, 2020 23:43
@eduardogoncalves
Copy link
Author

eduardogoncalves commented Oct 27, 2020

@mdo, as this has too many conflicts while retargeting to v4-dev... I create a branch from v4-dev and created a new PR #31979. And will close this one.

@eduardogoncalves
Copy link
Author

close in favor of #31979

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet