Closed inmanturbo closed 3 years ago
This is weird, I did get it to happen once but only on a users table. But now I can't get it to happen anymore so I don't know how to begin debugging it.
Unfortunately, chrome doesn't respect autocomplete=off, so that won't work.
https://bugs.chromium.org/p/chromium/issues/detail?id=914451
currently using, (sadly) this workaround:
{{--search.blade.php--}}
<input
wire:model{{ $this->searchFilterOptions }}="filters.search"
placeholder="{{ __('Search') }}"
type="text"
+ readonly
+ onfocus="this.removeAttribute('readonly');"
class="flex-1 shadow-sm border-gray-300 block w-full transition duration-150 ease-in-out sm:text-sm sm:leading-5 focus:outline-none focus:border-indigo-300 focus:shadow-outline-indigo @if (isset($filters['search']) && strlen($filters['search'])) rounded-none rounded-l-md @else rounded-md @endif"
/>
This is not ideal of course and still gives a dropdown of suggested emails on focus, which partially obstructs the user's view of the table, but at least it prevents chrome form tyrannically insisting one may only look up a user with the same email as the one they logged in with.
I just don't understand why it is doing it though? It doesn't have name="email"
or autocomplete="email"
or anything. It doesn't have a name at all because it doesn't need one.
What if we give it a random name on every page load that would never match anyone's autocomplete values?
I actually can't even get it to happen anymore, do you guys have steps to reproduce? It used to happen for me but not anymore and I didn't change anything.
When trying to find steps to reproduce we have discovered that strangely it only seems to happen when using tailwind. Also, in development environment you must go into chrome settings>privacy and security and toggle off "Warn you if passwords are exposed in a data breach" if you are using a basic dummy login such as admin@admin.com with "secret". Also it will only happen locally on "localhost" or "127.0.0.1" and not on "projectname.test", because of chromium security protocols.
I've just tried replicating on your Boilerplate project and it doesn't seem to be doing it anymore there. I was a few weeks ago.
You can see a development demo of one of our affected projects here: https://jetport.turbooffice.net
The source code is at https://github.com/digearthworks/jetport-menus/tree/development (the demo is on the development branch).
You can find the table component here: https://github.com/digearthworks/jetport-menus/blob/development/app/Core/Admin/Livewire/User/UsersTable.php
If you make sure your autofill setting are toggled on, turn off "Warn you if passwords are exposed in a data breach"
and login as admin@admin.com
with password secret
, then save the login info when chrome offers it, then browse to
https://jetport.turbooffice.net/admin/auth/users it should happen. Or it shouldn't, and yet it usually does.
Meh, maybe we should close this? As to the why: It doesn't make any sense! I've found many similar complaints and the more I research the more it looks like it's just a chrome issue. I guess with the right browser settings chrome will auto fill pretty much anything and everything.
Seems like an edge case for when users have specific chrome settings, and I don't think that the package will be able to solve this without hacking a workaround. There is certainly no reliable way to test for it.
I agree, I tried all of your previous reply I just forgot to reply back myself, and I actually could not replicate it with your application.
Hopefully it's just a bug Chrome will fix on its own that we won't have to deal with.
That being said if I come across it again on one of my apps, I'm going to try to fix it haha.
This is a strange one, I'm not sure why this happens. But it happens when you have a user table and search scoped to include email field. In dev tools I don't see a name attribute on the search and the type is equal to
text
so it seems like this shouldn't be happening. It may not actually be a bug with the package per se, but it sure makes it hard to use.