clicking a disabled submit opens the 1password save modal

Options
chrisdrackett
chrisdrackett
Community Member

I'm developing a website that has a disabled submit button on a password change form that becomes enabled when the password has been entered correctly twice. I've found that if you press the submit button before the form is valid the 1password modal comes up as if you submitted the form.


1Password Version: 6.0.1
Extension Version: 4.5.4.b2
OS Version: 10.11.4
Sync Type: Not Provided
Referrer: forum-search:clicking a disabled submit opens the 1password save modal

Comments

  • nathanvf
    nathanvf
    1Password Alumni
    edited January 2016
    Options

    Hi @chrisdrackett,

    That is indeed interesting.

    Can you describe a little exactly how your form operates? I imagine we are listening for some sort of form submission, I imagine if the submit button was disabled in the standard way and there was no action happening in JS it would not trigger the submit action in the extension.

    Let us know and we can maybe see what's happening.

    I imagine if you do a post for the form, then audit the form, and if it's empty you reload it. It will probably think you're successfully submitting.

  • chrisdrackett
    chrisdrackett
    Community Member
    Options

    I'm watching for submit events on the form and I don't see anything at all, I've also setup a global event listener, and while I see a click on the submit button, nothing is going on with the form. I probably need to start breaking the component down (we use react) to see the simplest case that causes this to happen.

    Something else that I'm doing that might not be as standard is that the button is in a label element. In my super simple test case I'm not getting the 1password dialog, but I'm not sure what actually triggers it in the first place :)

    http://codepen.io/anon/pen/XXYdWY?editors=1000

  • jxpx777
    jxpx777
    1Password Alumni
    Options

    @chrisdrackett Thanks for posting about this situation. We haven't always had so much positive interactivity with the web development community, so it's definitely not something we take for granted. I've been taking a look at this issue over the last couple days. First let me describe how autosave works and then I have a couple of questions for you.

    1Password's autosave feature looks at a few different things when deciding whether to trigger the autosave window. This is based on our experience over the years of examining lots of different sites and their various…erm…creative approaches to submitting forms. If everyone relied solely on the submit event, our job would be simple.

    In addition to the standard form submit event, we look at a few other events like clicks and keypresses events. So, in this case, when our event handler gets a click event, we look at the target and try to make some reasonable guesses about it. In addition to just looking at buttons and the like, we look at things like the target element's surrounding markup as well. For instance, on some sites, the image that is clicked might be buried in two other <div>s and the grandparent <div> might be marked as id="submitButton". It's bizarre, but it's the kind of thing we need to look out for in order to make autosave as robust as it can be.

    In playing with your CodePen, though, when the button is disabled, I don't even see the event fire when I click the button, which absolutely makes sense. Here's a fork that illustrates what I mean. (Be sure to show the console.) When I click on the disabled Submit element, I don't even get an event callback. This is what we want but it sounds like that's not happening in your case. So, this makes me think maybe the markup is slightly different to what is in the Pen or something else is happening.

    Notice that our event handlers are at the document level and we use capture. The reason for this is to work around some sites whose event handlers stop the propagation, so if we rely on bubbling, we will never get the event. We should never stop propagation of events or otherwise interfere with the page's operation. We really just want to know what's happening so we can take action on the user's behalf.

    All that being said, I would love to see the actual markup you're working with and help diagnose where the autosave is coming from and how we can help work around it.

    I hope this helps explain things a little bit better. I look forward to hearing how I can help.

    Thanks!

    --
    Jamie Phelps
    Code Wrangler @ AgileBits

This discussion has been closed.