IFrames with Dropkiq

Finding the absolute position of the mouse cursor (or more accurately, the "caret") is a surprisingly difficult programming challenge! This is extremely important for Dropkiq since our menu must be positioned in the right spot to have the UI that users expect. Luckily, the good people at Zurb have solved this problem in their TributeJS library. In fact, DropkiqUI is open source and if you dig in, you can see that we are reusing some of their code in order to solve this problem for our own Javascript library.

When it came to adding iframe support, we were lucky that we weren't starting from square one. TributeJS had already solved many of the problems of working with IFrames. However, there were still a few key challenges that we had to solve for.

Challenge #1

The first challenge with adding iframe support to DropkiqUI was that our suggestion menu was appearing underneath the iframe. Initially, we thought this was a style problem since the main page and iframes have separate CSS styles. However, after some research, we learned that it is not possible for content within an iframe to "overflow" into the main document (I'm guessing for security purposes).

Luckily, we were able to easily solve this by building the UI elements for the Dropkiq menu in the main page (even for a text area embedded in an iframe). When we detect that you are writing a Liquid expression in the iframe, the menu you are interacting with is actually on the main page even though it seems like it is in the iframe.

Challenge #2

Once the menu was being rendered on the main page instead of the iframe, we ran into a second problem that it wasn't being positioned correctly. This is because our default logic calculates the top and left distance from the text area you are typing in to the top left corner of the document it is embedded within. Basically, the menu was appearing where it should be appearing if the iframe was the main document.

To solve this, we simply needed to add the the distance from the top left of the main document to the top left corner of the embedded iframe. Once we did this, everything worked perfectly! The code for this turned out to be pretty simple. If we are in an iframe, add the distance to the top left corner.

if(this.iframe){
  var iframeRect = this.iframe.getBoundingClientRect();
  this.caretOffset['top'] = (this.caretOffset['top'] + iframeRect.top);
  this.caretOffset['left'] = (this.caretOffset['left'] + iframeRect.left);
}

Conclusion

Using iframes with Dropkiq has been a unique technical challenge for us, but a necessary one. Many WYSIWYG editors, such as Froala, use iframes to separate main page content from the editor content. Enabling DropkiqUI to work with iframes will open many possible WYSIWYG editor integrations for us. Unfortunately, it is not possible for our small team to test every single WYSIWYG editor on the market. Iframe support is a game changer for us. With iframe support, chances are we can integrate with most WYSIWYG editors.

‍
Check out our official documentation to learn more about using IFrames with DropkiqUI.