We need help with focus and control-key management!
We need help with focus and control-key management! If you are an expert in this domain, we’d like to talk to you about a potential contracting gig. Here are the details.
Our application is implemented as a SWF inside a web page. Most of our code lives inside the Flex universe and requires no help from the browser, but there are a couple of major limitations of Flex that we have to work around in order to build a real application inside a web browser: rich text clipboard support, and control key handling.
Our SWF takes up the entire visible area of the browser window, but in order to copy and paste to the system clipboard, we make sure that while the user is working in our main canvas, the browser focus is not in the SWF, but instead in an invisible DIV with contenteditable set to true (in IE), or an IFRAME with designmode on (in Firefox). Besides allowing us to read and write HTML to the system clipboard, this approach also allows us to trap control keys and prevent the browser from handling them.
This approach creates a couple of serious problems, however, and we have not yet been able to solve them to our satisfaction. The problems are related to the fact that under some circumstances it is important for the browser focus to come back into the SWF. In particular, when we want to use Flex input controls like mx:TextInput, the browser focus needs to come back to the SWF so that these controls will behave correctly.
Problem 1 occurs under Internet Explorer only: when the browser focus is in the SWF, and the SWF focus is in a text input field, and the user presses a control key that corresponds to a browser command, Flex does not appear to get a crack at the keyboard event, so there does not appear to be any way to prevent the browser from handling that command. A good example is Ctrl-F to bring up the browser’s Find dialog.
Problem 2 occurs under Firefox only: there does not appear to be any way in JavaScript to programmatically set the browser focus back into the SWF. So when the user is typing text into the word processing document, and the browser focus is in the invisible DIV, if the user presses a control key that is supposed to bring up a dialog in our application, we can’t get the browser focus back into the SWF. The result is that after pressing the control key, the user still has to click in the SWF before any of their typing will be recognized. Of course, this defeats the purpose of having a control key accelerator in the first place.
For each of these two problems, we have developed an approach to solving it, but we don’t really like the end result of implementing both solutions, because it takes our already complex focus handling code and makes it about twice as complicated as it already is, with additional code paths unique to each browser. Seems like it will be too fragile. But in the hopes that it might inspire you to come up with a better approach, here are the solutions we’ve prototyped.
For problem 1 (IE only), our prototype solution is that when the browser focus is in the SWF, we would handle the KEY_DOWN event for the Control key, and push focus out of the SWF and into the invisible DIV. Then, in the HTML page, we would handle the KEY_UP event for the Control key, and push focus back to the SWF. This appears to work, but requires some trickery to save and restore the selection in the mx:TextInput control and prevent the the focus highlight from being erased while the Control key is down.
For problem 2 (Firefox only), our prototype solution is that when we would like to set focus to the SWF programmatically (i.e., in response to a user keyboard command), we instead leave it in the invisible IFRAME. In this state, every time the user presses a key, we mirror the content and selection of the IFRAME into the mx:TextInput control in the SWF. Then, eventually the user will click in the SWF, and focus will return to it. This also requires some trickery, for example we would have to simulate the flashing cursor in the TextInput control, since Flash will hide it when it does not have browser focus.
Another approach that we have discussed is to always leave the focus in the invisible DIV or IFRAME, always push it away whenever the SWF gets focus, and always forward keyboard events to the SWF irrespective of whether SWF focus is in the word processing document or in a Flex control. So far we have not been able to get this approach to work even in prototype form, because things like mouse-based drag-selection get pretty confused when the focus keeps getting pushed away.
Suggestions are gratefully accepted. Even better, if you have a lot of experience solving problems in this domain, and you think you could probably come up with better approaches than the ones above, we’d be interested in talking to you about a contract gig.
Technorati Tags: Firefox, Flash, Flex, Internet Explorer
I'm working on Noteflight, an online music writing application that lets you create, view, print and hear music notation with professional quality, right in your web browser. Work on a score from any computer on the Internet, share it with other users, and embed it in your own pages. Noteflight is free for individual use. Email me at dcoletta at noteflight dot com.
Have a look here.
http://santrajan.blogspot.com/2007/03/cross-browser-keyboard-handler.html
David-
(In reference to “We need help with focus and control-key management!”)
I’ve had a hell of a time trying to solve a similar problem (getting F-keys to work in a Flash application embedded in IE). Unfortunately, we’re just going to avoid having hotkeys altogether because if we can’t follow the industry standard, we’d rather have nothing, and implementing a solution like what your team has done with Buzzword seems like a deadline-killer.
In any case, the problem we’re both facing is that browsers aren’t built for apps like what we’re building: Browsers are for rich media, not rich applications. The world needs something else.
Let me introduce myself a little. I’m a web application developer that’s been building web applications for almost 15 years, and I’m tired of the browser wars. I’m tired of cross-browser craziness, and most of all I’m tired of HTML/Javascript being what my software uses for presentation. Flash is good, but its stuck inside the same browserbox. Same goes for Flex — as it just uses HTML/Javascript/Flash in the end.
What could turn Flex into a killer development environment, however, is a new browser that’s built for APPS instead of MEDIA. It’s awesome to have Flash and Javascript allow for richer media, but a media browser should never get enough power to do the heavy lifting we need for an application. Function keys are an example, but there are TONS of other examples. Pop-ups. The ability to save to your local hard drive without the user knowing about it (for configuration files, for example). No back button, no reload button, only the buttons I put there. No address bar. Menus should be something my application has, not the Application Browser. A whole lot of compiled software should allow me to build those menus, also, instead of having to use html/css/images/javascript/flash/etc. The icon of my application should be on the users desktop, and when they double click it my application’s splash should appear if I so desire. And it should still be a server-delivered markup/scripting-language based app that is very much like a webpage, but isn’t quite.
As a developer, I’ve been making a wishlist of this kind of thing for 5 of those 15 years. I’ve toyed with the idea of making it, but there’s just no way I could. I’ve thought about trying to make it into an open-source project, but I never did. In fact, you’re the only person I’ve ever told about this vision. Maybe I think that since you work at Adobe you could convince them that its time they come out with their own version of a browser, something for delivering rich apps instead of rich media and solves alot of our problems when we’re working in developer-land. The great thing about Adobe doing it is it would allow EXTREMELY rich media in addition to just rich apps.
Well, maybe you don’t have that kind of influence. I’ll probably never know. But anyways, it was good to tell someone about it. And I did check out Buzzword — PHENOMENAL JOB. It’s gorgeous man.
Have a great day.
David Ash
@David Ash,
Did you just describe AIR?