It has come to 1Password's attention that file downloads don't work in Dropbox when the 1Password extension is installed in Safari. I did a technical deep dive into the issue and found the following Dropbox code that causes this issue. As we can see in the minified code below, the W function removes an iframe from the page:
c_downloads-vflIml6Dh.js
When a user initiates a download, an iframe is created to handle the request and calls the destructive W 100 milliseconds after the "load" event (see last line):
When 1Password is present, the load event will occur before the download occurs and Dropbox does not wait long enough. I believe this is because of how Safari works under the hood, where the time it takes for it to switch between JavaScript contexts (in this case 1Password and Dropbox) is slow. Here is a screen capture of me sharing the findings with my team internally:
You can see that although there is almost no time taken by 1Password between START_LISTENERS and END_LISTENERS (they have the same 1700750410578 timestamp because precision isn't high enough) as well as START_INJECTION and END_INJECTION, our mere existence causes a delay of 501 ms (1701750410598 - 1701750410097). I believe this is the root of the issue: 100 ms is too short a timeout.
This issue would not only affect 1Password / Dropbox users, but all Dropbox users that use any extension that injects code at document_start.
There are many ways to fix this, here is a list I came up with when investigating this issue. They all have different tradeoffs, and some may be impossible depending on Dropbox's internal requirements, but I wanted to share them for completeness:
- Use the download property of an anchor tag instead of dynamically creating/destroying iframes
- Increase the destructive timeout from 100ms to 1 second
- Rely on the iframe redirect event (ie "unload" event and not the "load" event + timeout)
- Create the iframe before the user needs to download their file and update it on user initiation.
