Closed ldexterldesign closed 5 months ago
Notion isn't using a <form>
component, which is bad practice. This makes it hard for buttercup to find where/if a login button should appear. Ideally we wouldn't need a form, but my fear is that this will create many false-positives. Notion should ideally fix their markup.
Let's keep this open, as we might find a way arounnd it.
@ldexterldesign Ha, thanks! Fixing the web one tweet+site at a time :smile:
I doubt they'll change it, and it simply means that we, the consumer, need to update how we detect login forms.
To be fair I've requested a bunch of features since I started using their [Notion] app' and they've been responsive. Only time will tell how many of my requests make it into production, and whether I stay using the app'.
Wow, thanks for adding bug status - harsh!
Sincerely
Same issue with http://reddit.com
[...] we, the consumer, need to update how we detect login forms
Mmm, think you're right
TBH injecting BC buttons in every form input would be better than nothing
Is all the BC form input button injection functionality in launch.js?:
Sincerely
@perry-mitchell what do you make of Buttercup not ignoring hidden form inputs?
Hope to hear back
Sincerely
Is all the BC form input button injection functionality in launch.js?
Actually no, it comes from the index here: https://github.com/buttercup/buttercup-browser-extension/blob/master/source/tab/index.js#L37-L76
And the engine to run that is locust, our login form scraper.
TBH injecting BC buttons in every form input would be better than nothing
This is actually a nice idea for a setting, however the issue lies in the ability to detect login forms, as Buttercup would not know how to fill a regular form. It only knows that usernames go in username fields and so on, so there'd be no point in adding buttons to other forms.
I think that Buttercup already adds them to all login forms it finds, too.
The remaining issues in my eyes for improved login form detection are:
Same issue with http://giffgaff.com
This issue combined with #338 currently making Buttercup logins a miserable UX for me 😔
When did buttercup start using locust because detection has gone downhill in recent months IMO - are we using locust scoring?:
Sincerely
TBH injecting BC buttons in every form input would be better than nothing
This is actually a nice idea for a setting, however the issue lies in the ability to detect login forms, as Buttercup would not know how to fill a regular form. It only knows that usernames go in username fields and so on, so there'd be no point in adding buttons to other forms.
Yes, I realised my comment was ill-considered after I published, but thanks for humouring me!
I think the interaction concept in my mind was: if some form input(s) exist/detected then don't show individual input buttons just show one generic call to action (e.g. located top right) to click so it populates forms - aside, some form inputs are so small this would actually be a welcome change (see Fitts's law), and the newly afforded screen real estate could yield more freedom with new buttercup (BC) features
The only use case I can think of where users (i.e. me) may want to be selective about the inputs entered would be order forms where (trivially) I want to populate the first name input but not the last name input. I don't currently use BC for this (but I would like to à la new BC features).
Sincerely
What do you make of Buttercup not ignoring hidden form inputs?
BUMP
what do you make of Buttercup not ignoring hidden form inputs?
Yeah, buttercup doesn't ignore hidden inputs. It should fetch all forms but the inputs that are used to deter autocompletion probably break it. This functionality would need to be handled here.
I've created an issue for the hidden inputs: buttercup/locust#37, and there was an existing one for the <form>
less logins: buttercup/locust#20
if some form input(s) exist/detected then don't show individual input buttons just show one generic call to action (e.g. located top right)
This is a great idea! I'd entertain a separate issue for this. Would be great under a setting, too, so users can choose what they prefer.
The only use case I can think of where users (i.e. me) may want to be selective about the inputs entered
There are some arguments I can think of for having them on-form:
And buttercup has auto-login functionality, so often times you don't even need to find the login, you can do this from the browser menu.
You've unconvinced me this is a good idea but I'll play devils advocate for a bit...
Multiple forms, which I see often (login vs register, are often on the same page and both get recognised)
Yes, this is what I mentioned above:
The only use case I can think of where users (i.e. me) may want to be selective about the inputs entered would be order forms where (trivially) I want to populate the first name input but not the last name input. I don't currently use BC for this (but I would like to à la new BC features).
We could potentially solve this more eloquently by having a bunch of selects in the CTA, for my use case:
[x] first name (checks when user selects item, can also auto-select single existing values by default or not)
> Lewis (I selected this > or it was auto-selected for me)
[ ] last name (not is my default otherwise this would have been auto-checked)
> Litanzos
SUBMIT
... and/or, for your use case:
[x] name
> Lewis (from some vcard)
[x] username
> ldexterldesign (from some vcard)
[x] email
>> foo@foo.com (from some vcard, I selected this >>)
> bar@foo.com (from some vcard, I didn't select this >)
SUBMIT
[x] username (from url detected entry)
>> foo (I have multiple accounts)
> bar (I have multiple accounts)
[x] password (from url detected entry)
>> *** (grouped by entry instead of input type vs. showing which entry this belongs (or both) would need consideration)
> ****
SUBMIT
I'm imagining the default UI position floated left/right of viewport with overflow for vertical scope and avoiding (hot) corners so users still likely to be able to see important UI elements, and offer custom position too
Browser auto-complete will often input my info for orders etc. but if I have multiple addresses then I always have to go in and prune things. Be useful to have the option to cherry pick from >1 entry if an entry won't suffice or doesn't exist - thing is, currently I get poor visibility on what an entry contains from the popup alone (e.g. not all fields visible, think this was mentioned in an issue but I can't find it):
[...] the newly afforded screen real estate could yield more freedom with new buttercup (BC) features
Related #95
More eye-catching for some users - exactly like a CTA but in situ
A big CTA is way more eye catching than a button in a form input IMO, and possibility to offer bigger click areas:
[...] some form inputs are so small this would actually be a welcome change (see Fitts's law)
Doesn't accidentally cover something somewhere else on the page, if we show a floating button in some corner (I have a lot of experience putting floating buttons on sites, it's a HUGE pain haha)
This is your best argument. I find myself getting pissed off recently by obtrusive remember password popups in vivaldi (think it's happened in other browsers too). The thing that pisses me off is not the size or position/placement, it's that it grabs focus like a modal so I must deal with it - I HATE THAT!
If users don't need our CTA then make it as easy as possible to work around (e.g. don't grab focus, let them click off/around it to dismiss it, hotkey to hide/show). 80% of the time an input is detected I need it - and that's the way it should be - so show everything (complete visibility of the entry fields; this should be the default with auto-login being the next fastest method.
Easy to find - The controls are exactly where you expect them to be, on the login
This comes back to Fitts's law - what would I rather click on, a small target close by (i.e. form input button) or a big target far away (i.e. CTA). It's debatable but I know I hate small targets and with the newly afforded screen real estate / helper features I could get used to a CTA instead.
Sincerely
Hi @perry-mitchell,
I hope you're well
Notion isn't using a
<form>
component
Did something change in the codebase because [Notion] auto login now functions (although it does now seem to use <form>
)?:
Aside, reddit login now functions too (always used <form>
)
Aisde, giffgaff still not detecting username
:
Hope to hear back
Sincerely
Hi @perry-mitchell! Locust is a great library and it works amazing in most scenarios. I've been following this thread. Twitter login and Apple (appstoreconnect.apple.com) also don't use forms so autofill doesn't work. I worry that since Apple is going in this direction too that it might become the norm eventually. Any plans to support autofill where there is no login form on the page?
Yes, there's a refactoring of our login form detection on the horizon.. it won't require any particular elements like
@perry-mitchell that's awesome! Can't wait!
The future is looking promising:
(Reddit)
(DigitalOcean)
Doing some testing and updates to the detection logic in prep for the new manifest v3 support. It should be vastly improved once out.
Login form detection etc. has been improved in V3, but not all issues here have been addressed. Still need to check the hidden inputs and double-check the input button type. Right now V3 uses the old button type, and supports the new type, but doesn't provide an option to change it. That can be added in an upcoming issue.
Hi!
No Buttercup form interaction (i.e. login buttons) with Notion
Tested in the following, so doubtful it's browser incompatibility:
Sorry for brevity
Hope this helps!
Sincerely