From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 BuildID: 2001122106 i can't enter new url to url bar because there is couple of Java applets running (site url:www.sm-liiga.fi). If I press ctrl+l it doesn't work but ctrl+shift+l works still fine. Also if i click on url bar it doesn't help (=I can't enter new url). I have noticed this problem on few other sites (I don't remember url) and on those sites there were Java applets. Reproducible: Sometimes Steps to Reproduce: 1.I go to site (url: www.sm-liiga.fi) 2.There is Jaca applet on the left 3.I wait until everything is loaded 4.Then I click the Java applet Actual Results: I can't enter new url on url bar. Ctrl+l doesn't work but ctrl+shift works. Expected Results: I should be able to enter new url to url bar and ctrl+l command should work

Confirming on 2002011503 Win2k: I can't get the focus for the URL bar by pressing CTRL+L or CTRL+Shift+L. Clicking on the URL bar gets me a cursor, though.

This has been bugging me for some time under Linux OS --> All Ctrl-w also does not work to close the window, this might be some kind of focus issue --> updating summary, reassign to keyboard navigation This might belong in OJI, reassign as necessary.

This is a major accessibilty bug, and blocks our legal compliance to the Federal Rehabilation Act Section 508, which requires keyboard accessibility in our product. Section 508 compliance is a requirement.

-> Java

I think this is a dup of #95541. I think the reason of the bug is the code (and comments) at widget/src/gtkxtbin/gtkxtbin.c: /* Turn off any event catching for this window by */ /* the Gtk/Gdk event loop... otherwise some strange */ /* things happen */ XSelectInput(GDK_WINDOW_XDISPLAY(widget->window), GDK_WINDOW_XWINDOW(widget->window), 0); gdk_window_set_user_data (widget->window, xtbin); widget->style = gtk_style_attach (widget->style, widget->window); gtk_style_set_background (widget->style, widget->window, GTK_STATE_NORMAL);

There are two event loops on Homepage with a Java Applet. one is browser's and the other is Applet's When you set focus on Applet(click Applet), the keyboard event is processed by Applet, the Applet don't identify Ctrl+L and Ctrl+Shift+L, So Ctrl+L and Ctrl+Shift+L will not work. If you click outside of Applet, browser will process the keyboard event, so Ctrl+L and Ctrl+Shift+L will work.

This is not a dup of 95541 buttboth these bugs have the same reason. I provided patch for 95541 and I think I'll provide fix for this bug soon.

I think this bug should be fixed in mozilla's plugin module because all plugin (include flash ans so on) filter the Ctrl+L and Ctrl+Shift+L event.

reassign to me

Confirm on Linux(RH8.0)/Windows2000 mozilla1.2 JRE1.4.1_01 Both Ctrl+L and Ctrl+Shift+L doesn't work. Should we define a short cut key that we can leave the object element? For example, Ctrl+Shift+<a key>. If user press that shortkey, the object element will blur the focus and return the focus to the document.

This is just one case of a more general bug, which still happens in 2003061603, Mac OS X. It stops all keyboard input outside the applet, not just shortcut keys and the URL bar. The problem is that once an applet has the keyboard focus, as long as it is still running it will not let go of the keyboard focus for the window it's in, even if you switch tabs. Hence whatever you've clicked outside the applet, the keystrokes continue to go to the applet.

If you set focus on plugin (Applet, Flash and so on), the shortcut such as Ctrl+L and Ctrl+Shift+L is only work for plugin. I suggest mark this bug as WONTFIX

Suggest marking what as WONTFIX, exactly? The fact that applets don't forward keyboard shortcuts to the rest of Mozilla, or that an applet permanently hogs the focus?

It appears to me that the behavior isn't always the same with applets and other plug-ins. with 1.5rc1 on w2k: http://www.valeo.com/gb/press/news.asp loads an applet without doing anything but letting the page load, the user looses the focus on the page and can't use any keyboard shortcut http://www.rolexmentorprotege.com/home.html loads a flash movie and there, the focus is kept on the window, why ?? (because of javascript code at the end of the page ?)

Still a problem in nightly builds. Tried Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031020 Internet Explorer or iCab does not exhibit this behaviour for the same java plugin (1.3.1) Alternative URL to show the problem: http://smarttv.dk/~jnp/test/applet/

->kyle

I am experiencing a similar keyboard focus problem with my applet. What I've basically seen is that once an applet gets the keyboard focus, it is very reluctant to give it up. I did notice different behavior in Netscape 7.01 (Gecko/20021120) running on Mac OS 10.2.8. The test I had been running was to load an applet with a text area in an html page with a form <textarea> and attempt to type in each. Through the recent 1.6 release, once I type text into the applet text area (be it an AWT or Swing component (TextArea or JTextArea)), I am able to click in the html text area and the caret blinks where I type, but anything I type is entered into the applet text area. Again, Gecko 20021120 behaved differently. If I use an AWT TextArea, everything works properly. I can type into either text area and switch between the two. Using a Swing JTextArea, however will result in a crash at step three: 1) Type text into html textarea (works), 2) Type into JTextArea (works), 3) Type into html textarea (crash). Perhaps there was a fix introduced to prevent the crash that is preventing keyboard focus from being properly released?

situation described in #14 still true with 1.7 build 20040208

I think this is a dup of bug 78414.

I agree, they are all about plugins block the (keyboard) events from propagating. *** This bug has been marked as a duplicate of 78414 ***

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

Since this has been duped, and since the two issues are really separate, I've reopened the issue of comment 11 as bug 247140.