User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040830 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040830 When a flash movie is run under a recent Mac OSX nightly build, all keyboard input seems to be ignored. A good example is to go to http://www.macromedia.com and trying to enter text into the search field in the upper right. When you click in the text box the text cursor will not appear nor can you type anything into the field. Running a Flash movie that uses keyboard listeners (ie games at http://www.yetisports.org/ or http://www.ebaumsworld.com/), also dont get keyboard input. I've tested this on a recent nightly for Windows and it works fine (haven't tested Linux yet). The latest released versions for OSX work fine, just the nightly's show the problem (something to do with the new Quartz rendering?) Reproducible: Always Steps to Reproduce: 1. go to http://www.macromedia.com/ 2. try to click on and type into the search field at the upper right Actual Results: The text cursor does not appear in the field, nor does any typed text Expected Results: You should be able to type into a flash text field, or use any flash movie that has keyboard listeners Appears to be happening only on OSX nightly builds

seems scriptability is broken, test available at: http://www.macromedia.com/support/flash/ts/documents/java_script_comm/javascript_to_flash.html Of course js must be enabled, otherwise you won´t see the flashbox on this page. On windows, you don´t have scriptability if you "install" a mozilla from zip-package, as there is flashplayer.xpt missing from the components directory. Workaround on windows: copy flashplayer.xpt from some older installation, mine is from february 2003.

forget comment 1, the example from comment 0 is worksforme also, when scripting is disabled, flashplayer.xpt removed from the components folder.

In firefox of branch, while FAYT works, a character can be inputted somehow. However, this is very bad. And in Camino of trunk, FAYT only works. A character cannot be inputted. Mac OS X 10.3.5 Camino 2004083103 (v0.8+) Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7.3) Gecko/20040830 Firefox/0.9.1+ flash plugin 7.0r24

Bug 228298 is just for camino, but the cause might be the same.

I believe this is a duplicate of bug 264129 (which has a terrible summary) *** This bug has been marked as a duplicate of 264129 ***

I'm going to unduplicate this becuase typing seems to be a specific type of bustage, and this bug is more specific.

This testcase shows that flash in an <object> tag works fine, but in an <embed> tag fails.

So when did this break? Anyone have any idea?

The difference between <object> and <embed> seems to be the way that Flash is handling keyboard input. For <embed> (which does not work), keyboard events are coming in via TSM (aka IME). For <object> they are coming in via the normal WaitNextEvent path. So I think this is a Flash behavioural difference.

Despite the different routine of key events by the OS, we have code that dispatches both through the same paths into gecko. After this, the difference seems to be when the event reaches PresShell::HandleEvent(). For the <object> tag mCurrentEventFrame is non-null. For the <embed> case it's null.

It seems that we don't give focus to <embeds> (ESM's call to frame->IsFocusable() ends up in nsGenericHTMLElement::IsFocusable() which returns false), but we do give focus to <objects> (nsHTMLObjectElement::IsFocusable() returns true). nsGenericHTMLElement::IsFocusable() consults tab index to decide if something is focussable. If I add a "tabindex" attribute to the <embed> tag, then typing works.

So should <embeds> get their own nsHTML_Element class which has a different IsFocusable() impl, should we add IsFocusable() to nsHTMLSharedElement, or should this be fixed another way? Also, why did it break on the trunk? The IsFocusable() stuff landed on 2004-07-24, so it would be interesting to see if older builds work.

*** Bug 228298 has been marked as a duplicate of this bug. ***

Yup, this work in Firefox trunk 2004-07-23, and is broken in 2004-07-31. That points to aaron's checkins for bug 250006.

Comment on attachment 172015 [details] [diff] [review] So this should fix it, right? I don't think you need to do the form element check for these, they can just be tabbable and focusable all the time. That means we don't need to implement IsFocusable. All you need to do is add the tabindex support so that the default tabindex is 0 and nsGenericHTMLElement::IsFocusable impl will handle the rest.

Comment on attachment 172015 [details] [diff] [review] So this should fix it, right? >+PRBool >+nsHTMLSharedElement::IsFocusable(PRInt32* aTabIndex) >+{ >+ PRBool rv = nsGenericHTMLElement::IsFocusable(aTabIndex); >+ if (!rv || !mNodeInfo->Equals(nsHTMLAtoms::embed)) { >+ return rv; >+ } Minor nit: when I see 'rv' I automatically assume it's an nsresult. Maybe call it 'isFocusable'.

Comment on attachment 172015 [details] [diff] [review] So this should fix it, right? Okay, if you want to, treat them as form controls since they can be submitted. But I would be fine if you didn't too. It won't hurt anyone if they're always tabbable. So remove the IsFocusable() impl's if you want to save a little code. Please change rv to isFocusable. I'm accustomed to rv always being an nsresult, and we should use meaningful names when possible.

Comment on attachment 172015 [details] [diff] [review] So this should fix it, right? sr=jst

(In reply to comment #15) > Created an attachment (id=172015) [edit] > So this should fix it, right? > just an fyi .. applied this patch as is to tonight's cvs (012105) and things seem to be working fine, Flash is accepting keyboard input. (compared to the latest osx trunk from today today, in which flash does not accept input from the keyboard)

checked in, but I took aaron's advice and removed the IsFocusable impls. He's right that applets and embeds are really not form controls as far as the user is concerned.

Fixing this caused keydead situations to occur when you tab to one of these objects. A keydead situation is just as bad as a crash for a keyboard-only user. So we can fix the original report which involved clicking into the search field and also prevent the keydead situations by making these objects focusable but not tabbable. I have filed bug 309704 for that. Note that eventually we need to make the tabbable contents of a plugin tabbable, but not the plugin object itself. We'll do that when we can make sure that people can tab out.