Failed to fillFrame: Frame is missing uuid.

edited December 2021 in 1Password in the Browser

Hi there! We are developing websites locally (specifically developing the WooCommerce Blocks plugin for WooCommerce. We have noticed a bug when using 1 Password to fill in the address on the checkout form locally (but not on normal websites).

Failed to fillFrame: Frame is missing uuid.
(anonymous) @ injected.js:4
(anonymous) @ injected.js:4
(anonymous) @ injected.js:4
n @ injected.js:4

The related issue in the WooCommerce Blocks repository can be found at the following URL:

Thanks in advance for your help :)

1Password Version: 7.9.2
Extension Version: 2.1.4
OS Version: macOS Big Sur 11.5.2
Referrer: forum-search:fillFrame


  • ag_jarekag_jarek

    Team Member

    Hiya @opr! Jarek from the Browser Experience team here 👋

    That's an interesting issue for sure. To make sure I'm understanding this correctly:

    • The autofill operation is completing successfully and all fields are being filled as expected
    • However, on development sites only, the field validation routines aren't being properly triggered and are showing the autofilled fields as not being filled out properly

    Does that sound right? Also, is there a good way to reproduce this issue on our machines (how hard is it to set up the test site mentioned in the issue?).

  • Hey there @ag_jarek

    Yes you have understood perfectly, except I've looked into this again after the holidays and it is happening on normal sites too. I'm using Brave browser, by the way.

    You may use my testing site to check this out if you add some items to your cart from the Shop page, then head directly to Checkout, you can try autofilling the address there.

    You may use the test card number 4242 4242 4242 4242 with any expiry and any CVV, when you press checkout the errors show up

    If you need to set this up locally I can provide more instructions but it's a little more involved.


  • ag_jarekag_jarek

    Team Member

    Thanks for the link to the demo site @opr! That was very helpful :)

    I took a look at that and as far as I can tell the autofill operation is completing successfully on our end; I didn't notice any errors coming from our scripts or other abnormal behaviors. I was able to reproduce the site not believing the inputs had been filled after we autofilled them, though.

    I discovered something interesting; if I autofilled the fields, left the checkout page and returned to my cart, and then clicked "Checkout" again, the fields would be pre-filled with what I had autofilled prior to leaving the checkout page.

    If I autofilled new data into the fields at that point and clicked "Place Order", everything worked great and the site didn't complain about the fields not being filled out. Given this discovery, it looks like we need to work out how to get the site to recognize 1Password has autofilled data so that it knows the fields do indeed have data in them.

    Here are the steps our fill script takes in order to autofill each individual field:

    • Click the field
    • Focus the field
    • Dispatch three events for the field: KeyDown, KeyPress, KeyUp
    • Set the value of the field to the data being filled (element.value = value;)
    • Dispatch five events for the field: KeyDown, KeyPress, KeyUp, Input, Change
    • Set a background color on the field to denote that it was filled
    • Blur the field

    The best way for the site to recognize that 1Password has filled data would likely be to notice that the field has a non-empty value. Otherwise, the above events that we trigger on each field in the process of performing our fill should provide some useful places to know to run input validation.

    Let me know if that helps out! I'd be happy to answer any further questions as they arise.

  • Hi there, thanks for looking into it!

    if I autofilled the fields, left the checkout page and returned to my cart, and then clicked "Checkout" again, the fields would be pre-filled with what I had autofilled prior to leaving the checkout page.

    Ah this is part of the WooCommerce Blocks functionality, it saves your data in a draft order so when you return you don't have to fill it in again.

    Interesting discoveries you've made, what I am seeing is that when going via the browser extension button and autofilling from this panel

    the onBlur event is fired.

    When using the autofill this way, via the autocomplete box attached to the input it isn't.

    You can execute this script on the checkout page in the JavaScript console to listen for onBlur events and see which fields and what the values are when they're blurred.

    const x = i => console.log( { id: 'id' ), value: } ); Array.from( document.getElementsByTagName('input') ).forEach( a => a.addEventListener( 'blur', x ) );
  • ag_jarekag_jarek

    Team Member

    @opr interesting! Thanks for pointing that out, I dug into that and you're absolutely right. We are calling element.blur() on elements when we're done filling them, but for whatever reason that doesn't appear to be consistently firing blur events across all browsers (in Firefox the blur event seems to almost always be firing, while in Chromium-based browsers it's firing in less circumstances). I tried manually firing a blur event on elements being filled via element.dispatchEvent(), and sure enough, input validation on was then perfectly happy. No issues.

    I'll file an issue for this internally so we can look into things and see what we can do to ensure consistent blur event behavior across all browsers. Thank you for bringing this up!

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file