Why frameworks are not a silver bullet for rapid development...

It had been a while since I'd worked on my current OSX app. The code seemed strange and unfriendly. But after a few hours of re-introducing myself to everything I'd written over the last year, I managed to find my groove again. That is, until I decided to try a new interface for one of the pieces of functionality. I'd actually done the same thing in another area of the application before, so it should be easy, right?

The coding gods were not on my side.

I was trying to simply turn a div inside a WebView into a contenteditable div. This basically meant putting:

contenteditable="true"

on the div tag. Try as I might, I could not get that content to be editable. To make it even more frustrating, copying the same generated HTML content out of my application and into a regular HTML page allowed me to edit the content I wanted to without issue.

There were no error messages. I whipped out the google-fu on "WebView contenteditable" and other variations and could find nothing. I tried explicitly setting the WebView component to be editable. Nothing.

By luck, I ended up stumbling on the following in my code:

- (BOOL)canBecomeKeyWindow {
  return YES;
}

which must have been how I made the other contenteditable area work. Sure enough, that was it. You run into problems like this often with frameworks. Simple things become incredibly difficult because you haven't flipped the right switch. You haven't flipped the right switch because no one said you had to. No one said you had to because they didn't predict you'd try to do this specific thing with the framework. But I did. And now after endless hours of frustration, I know not to make that mistake again. Onto the next one!

(297 words)