ivanjonas / login-manager Goto Github PK

Both during creation and editing of logins

Ctrl+up, Ctrl+down, and some other combo while focused in the login form should "focus" on and navigate between Logins and submit that login.

Include useful active/focus styles

When targeting mode is enabled to select a location for the LM, it may be difficult or impossible to return to the button that cancels targeting. In that case, pressing Esc should cancel targeting mode.

(This issue previously specified an event handler to also confirm the placement of the LM. This is no longer necessary because clicking the target that is currently being hovered is equivalent to clicking the drop zone. )

Nothing entered into those fields is expected to conform to spelling rules.

Suppose the target application login form has two fields (username and password) and a Submit button. Ensure that pressing, say, Shift+Enter while focus is inside the fields or on the Submit button will silently create a new Login and submit the form. This avoids the unpleasant situation where the user has just finished typing both UN and PW into the form fields and realizes that he needs to first click the Add New Login button inside the Login Manager and re-type those two fields.

The width of the LoginManager is fluid and adapts to the length of the logins (but respecting min and max Login width). This can cause a jarring experience when removing logins: the window may suddenly shrink.

Currently, an errant click might nuke a Login. Destructive actions should be confirmed.

Since the LM needs to be injected into the page, there must first exist a button outside the LM that can inject it into the page.

The same goes for the other dynamic location functions: choosing the UN and PW fields and the Submit button. Create buttons for each of those in the fixed toolbar. If any button has already successfully been used in the toolbar, move it inside the LM itself.

I envision a fixed toolbar in a corner of the page that dramatically calls attention to itself with a spotlight effect. The fixed toolbar should be visible while the LM isn't injected into any element on the page (future issue will probably be submitted to deal with LM targets that are injected into the page after a time. In that situation, a timeout should ensure that the spotlight effect isn't triggered unnecessarily). Also take care to only show the spotlight once. If the user has already seen the spotlight and taken no action, they probably do not want to inject the LM right now.

Maybe a blank password should be accepted?

Related to #8. Functionality to use the mouse cursor to determine where to inject the Password Manager.

Identifying the location of the widget itself might be more complicated. One potential is the following: on activation, add outline: 1px solid red to whatever element is being hovered (the "container element"). On click, a widget with dummy data is injected as the first child of the container element; a second UI with two buttons will allow the widget to be injected as the last, second, third (etc) element, depending on how many children are already present in the container element.

Further configuration may be useful, such as alignment, margin/padding, etc.

Save user preferences to localStorage.

The area in the image below is buggy. Hovering over it does not highlight the Login (parent element), and clicking does not register.

This is useful in two cases. First, when the login form is a multiform. When the same fields are used for both login and account creation, the account creation may be the default action. Second, when the login form is poorly-coded and does not have a default submission action that can be triggered with an Enter key event, but instead relies on a generic ajax call from a generic non-submission button. For simplicity, all login actions from the Login Manager should use this explicitly-chosen button.

Potential problem: a form that only relies on keyboard submission and does not have an Enter button. There should be an option for that.

Initial versions of the program will require the user to use JavaScript to identify the fields that Login Manager needs to hook into (as well as the location of the password manager itself). I envision a function that allows the user to merely click to identify those elements.

Save user preferences to localStorage.