ldexterldesign commented 3 years ago

Hi!

No Buttercup form interaction (i.e. login buttons) with Notion

Tested in the following, so doubtful it's browser incompatibility:

Firefox, v80.0.1 (64-bit)
Vivaldi, v3.3.2022.36 (Stable channel) (64-bit)

Sorry for brevity

Hope this helps!

Sincerely

perry-mitchell commented 3 years 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.

perry-mitchell commented 3 years ago

Let's keep this open, as we might find a way arounnd it.

ldexterldesign commented 3 years ago

FYI https://twitter.com/ldexterldesign/status/1309682673007419394

perry-mitchell commented 3 years ago

@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.

ldexterldesign commented 3 years ago

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

ldexterldesign commented 3 years ago

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?:

If yes then, if it's helpful, I'll scan the code again and be in a better position to brainstorm form detection
If no then feel free to link

Sincerely

ldexterldesign commented 3 years ago

@perry-mitchell what do you make of Buttercup not ignoring hidden form inputs?

Hope to hear back

Sincerely

perry-mitchell commented 3 years ago

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:

Iframe support (this repo #288 + locust)
No-form-element support (locust)

ldexterldesign commented 3 years ago

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?:

If yes then can this be tweaked for the use cases in this issue
If no then I think it would be useful to try

Sincerely

ldexterldesign commented 3 years ago

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

ldexterldesign commented 3 years ago

What do you make of Buttercup not ignoring hidden form inputs?

BUMP

perry-mitchell commented 3 years ago

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

perry-mitchell commented 3 years ago

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:

Multiple forms, which I see often (login vs register, are often on the same page and both get recognised)
More eye-catching for some users - exactly like a CTA but in situ
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)
Easy to find - The controls are exactly where you expect them to be, on the login

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.

ldexterldesign commented 3 years ago

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:

register

[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

log in

[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

ldexterldesign commented 3 years ago

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

danline commented 2 years ago

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?

perry-mitchell commented 2 years ago

Yes, there's a refactoring of our login form detection on the horizon.. it won't require any particular elements like

danline commented 2 years ago

@perry-mitchell that's awesome! Can't wait!

perry-mitchell commented 1 year ago

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.

ldexterldesign commented 1 year ago

https://youtu.be/T1GBbcnwOHs?t=25

perry-mitchell commented 5 months ago

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.

464 for the login button customisation.

buttercup / buttercup-browser-extension

Enhance form login detection #Enhancement #374

register

log in

464 for the login button customisation.