Ignore password managers on new page name field

[c0shea]

Describe the feature you'd like

When creating a new page, some password managers (like 1Password and Keeper) try to autofill the page title/name field with an identity or credentials.

Describe the benefits this would bring to existing BookStack users

This would make it less annoying having to either delete what the password manager autofilled or clicking away from pop-up suggestions that the password manager is suggesting.

Can the goal of this request already be achieved via other means?

No. With 1Password, you can tell it to ignore this page, but it's not ephemeral. It only remembers that for the current page load.

Have you searched for an existing open/closed issue?

• I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

1 to 5 years

Additional context

To disable the password manager functionality on the page title field, it's as simple as adding the attributes data-1p-ignore and class="keeper-ignore" to the input text field. I see that the new page form uses the resources/views/form/text.blade.php common helper, but I'm not sure how to generically extend that to conditionally add both of those attributes, especially since the class attribute already exists and would need a second value (keeper-ignore) added.

[ssddanbrown]

Hi @c0shea, Thanks for the suggestion.

I'm really not keen on adding vendor/software/extension-specific elements like that.
I guess we could maybe use less generic field names (page-name instead of name) but overall I'm not keen on making changes and/or adding complexities (even if minor) to suit decisions or limitations in external specific software.

[c0shea]

Thanks, @ssddanbrown. I understand not wanting to add support for the never-ending list of vendor software. I like your idea of making the element names less generic (page-name etc.) so hopefully the extensions don't recognize them as something they are not.

[Hecke29]

Hi, I played around a bit (on book create).

Setting autocomplete="off" (which would be a considerable thing in my opinion) will prompt 1password to not directly pop up: You'll not get the suggestion-thing at the bottom whilst the clickable Icon on the right stays (but must be clicked in order to get suggestions).

When changing id and name to book-name instead of name 1password will still be there.
Additionally changing the content of the label (!) to Book-{{ trans('common.name') }} will make 1password not recognize this field anymore.

If the id / name of the input or the label content is Name 1password will generally recognize the field as "maybe you want your name in here?" which is quite interesting to know.

In my opinion the solution with autocomplete=off would be totally fine and has a low risk of breaking something. I could implement that?

[Hecke29]

@c0shea would you be happy with my described solution?

[c0shea]

@Hecke29 that sounds good to me. I can't see why anyone would want their web browser or password manager extension to try to auto fill the page name field.

[Hecke29]

@ssddanbrown is it okay for you to change those kind of inputs to autocomplete=off? I could do it in code just want to be sure it’s something you can see as a valid solution

[ssddanbrown]

@Hecke29 It still doesn't feel right to me. If we were making that change based upon the user feedback of normal autocomplete being a common nuisance, I'd be all for it. But we're making the change based upon the dodgy behaviour of an external browser extension, which makes me think this should be the responsibility of 1password.

There is some utility to the native auto-complete, I sometimes use it myself if I need to create a bunch of content with similar names (Sure I could copy/paste, but I don't always think ahead).