Closed Bug 718939 Opened 13 years ago Closed 13 years ago

Java applet causes text entry fields to become semi-unresponsive

Categories

(Core :: Widget: Win32, defect)

10 Branch
All
Windows 7
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla13
Tracking Status
firefox10 + verified
firefox11 + verified
firefox12 + verified
firefox13 --- verified
firefox-esr10 10+ verified

People

(Reporter: krazywrath, Assigned: cpearce)

References

Details

(4 keywords)

Attachments

(5 files)

Overview: Interacting with an embedded Java applet (e.g. clicking inside a Java game) causes all text entry fields to become virtually unusable until one 'un-focuses' the Firefox window (i.e. by minimizing or resizing it). This affects the location and search bars as well. Build ID: Bug found in the following builds, but not the stable version Nightly - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120117 Firefox/12.0a1 ID:20120117031056 Aurora - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a2) Gecko/20120117 Firefox/11.0a2 ID:20120117042008 Beta - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0 ID:20120111092507 Steps to Reproduce: 1) Find a webpage with an embedded Java applet such as [[http://chir.ag/stuff/sand/]] 2) Click into the Java applet Actual Results: User becomes unable to type or select text in the Location Bar, Search Bar, or any text entry field Expected Results: User should be able to type or select text in any text entry field
confirming with Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120117 Firefox/12.0a1 SeaMonkey/2.9a1 and JRE 6.0.300.12 requesting tracking because this is a serious regression. Last good nightly: 2011-11-08 First bad nightly: 2011-11-09 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-11-08&enddate=2 011-11-09
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Java-Implemented Plugins → Plug-ins
Ever confirmed: true
Keywords: regression
Hardware: x86_64 → All
(In reply to Matthias Versen (Matti) from comment #1) > confirming with Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120117 > Firefox/12.0a1 SeaMonkey/2.9a1 and JRE 6.0.300.12 > > requesting tracking because this is a serious regression. > > Last good nightly: 2011-11-08 > First bad nightly: 2011-11-09 Tracking for FF11/12, but it's unclear from merge calendar [1] (and my attempt to reproduce) that FF10 is affected. [1] https://wiki.mozilla.org/RapidRelease/Calendar
Please re-nominate for FF10 if it ends up being affected.
(In reply to Alex Keybl [:akeybl] from comment #3) > Please re-nominate for FF10 if it ends up being affected. Are you using Windows 7, and Java 6.0.300.12 as well? I've tried this on a new profile and safe mode as well, both ending with this problem.
(In reply to Eric [krazywrath] from comment #4) > (In reply to Alex Keybl [:akeybl] from comment #3) > > Please re-nominate for FF10 if it ends up being affected. > > Are you using Windows 7, and Java 6.0.300.12 as well? Thanks, it wasn't clear that this was Windows only. We'll track for 10 in case we end up getting a number of dupes, but I don't think we can expect to have a low-risk fix ready for FF10 at this point.
Assignee: blackconnect → nobody
QA Contact: blackconnect → plugins
Blocks: 699885
Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/81dedcc49ac0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111108 Firefox/10.0a1 ID:20111108031146 Fails: http://hg.mozilla.org/mozilla-central/rev/c170948e646e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111108 Firefox/10.0a1 ID:20111108000404 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=81dedcc49ac0&tochange=c170948e646e Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/f70682372656 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111107 Firefox/10.0a1 ID:20111107143440 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/be3714af7869 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111107 Firefox/10.0a1 ID:20111107173846 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f70682372656&tochange=be3714af7869 Regressed by: bea7ecf9084e Chris Pearce — Bug 699885 part 1 - Ensure we dispatch 'deactivate' event to chrome window when we lose focus while changing to full-screen mode. r=roc
Component: Plug-ins → DOM: Core & HTML
QA Contact: plugins → general
I am also experiencing this bug in an internal enterprise web application using Firefox 10. When the java applet loads, you cannot see the text cursor/selection in input boxes either on the web page or in the Firefox application (location bar and history does not show up). Minimizing the window fixes the problem.
merge with 713607
Possible workaround: http://forums.mozillazine.org/viewtopic.php?p=11703665#p11703665 Set about:config > dom.ipc.plugins.java.enabled = true Add new boolean about:config > dom.ipc.plugins.enabled.npjp2.dll = true Restart Firefox.
I tried it. Doesn't work.
no matter it is oopp or not, it won't work
akeybl: could you add this bug to the known issue list on the Firefox 10+ Release Notes?
Keywords: relnote
Hello, We have the same bug in our web application. This is a serious issue for us as our application is used by our customers. Please, could you assigned somebody to work on this issue ? Best regards
(In reply to MS from comment #20) > Hello, > We have the same bug in our web application. This is a serious issue for us > as our application is used by our customers. MS, please provide as much information as possible about the affected web application, the user effect, etc. Thanks!
Version: 12 Branch → 10 Branch
(In reply to Alex Keybl [:akeybl] from comment #21) > > MS, please provide as much information as possible about the affected web > application, the user effect, etc. Thanks! The internal application I am using that this effects uses Java applets to display charts. As soon as the Java applet runs: * Text selection works, but the visual indication no longer appears to the user, making text selection and editing very difficult * The location bar in the Firefox Application becomes non-functional - it will display no history when typing, and hitting enter no longer works * These issues are true of every tab, not just the one running the Java applet A typical user will generate many charts in a short time with this tool, and these issues will be encountered after each request. Minimizing the window and restoring it fixes the problem, but users will not realize this. Most colleagues I have talked with end up restarting the web browser completely. I would classify the user impact as severe since it actually "breaks" the Firefox application.
I can easily reproduce this on Firefox 10 on Windows 7 64-bit with Java SE 6.0.290.11. 1) Download and install Firefox 10, start with a new profile 2) Open http://chir.ag/stuff/sand/ -> prompted to install Java 3) Install Java -> page reloads 4) Try some text fields (ex. location bar, search box, google on the home page, etc) Result: No text boxes work until I restart Firefox
Flags: in-litmus?
(In reply to Alex Keybl [:akeybl] from comment #21) > (In reply to MS from comment #20) > > Hello, > > We have the same bug in our web application. This is a serious issue for us > > as our application is used by our customers. > > MS, please provide as much information as possible about the affected web > application, the user effect, etc. Thanks! Hello Alex, Our web application is used by airlines in critical environment. That's why it's a serious regression for us. Sorry but I can't give you a scenario to reproduce it on our application, but I can give you those following details : WINDOWS XP FIREFOX 10.0 JAVA 1.6
1. go http://java.sun.com/applets/jdk/1.4/index.html 2. Click Demo and click applet to focus it 3. Click text fields (ex. location bar, search box, google on the home page, etc)
(following my last comment #24) Impacts in our application: When the applet is loaded, the focus cursor is missing in all textfields in Firefox (location bar, search field and in all tabs opened). Even the :focus css rules is not applied to any input field in our page. But we are still able to enter text. Workaround : The workaround given by Loic in comment #16 doesn't work. But we found that if firefox loses the focus and then gets the focus, the issue disapears and everything comes back to the normal. Alice0775 : We have the same behaviour the scenario given in your comment #25.
Component: DOM: Core & HTML → Widget: Win32
QA Contact: general → win32
Well fix this by backing out bea7ecf9084e.
Try push: https://tbpl.mozilla.org/?tree=Try&rev=4db261dee3f3 Will wait for QA+ on Try builds and for test to go green before requesting approval for landing.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #595168 - Flags: review+
Juan and I spent some time testing the fix on the tryserver build. You can see the results of our Windows testing here: https://etherpad.mozilla.org/Bug-718939. We believe based on this it is good to land so you have our QA+. (In reply to Chris Pearce (:cpearce) (on paternity leave, don't expect quick response!) from comment #28) > Created attachment 595168 [details] [diff] [review] > Patch: backout bea7ecf9084e from m-r > > Try push: https://tbpl.mozilla.org/?tree=Try&rev=4db261dee3f3 > > Will wait for QA+ on Try builds and for test to go green before requesting > approval for landing.
Attachment #595168 - Flags: approval-mozilla-release+
Attachment #595175 - Flags: approval-mozilla-beta+
Attachment #595206 - Flags: approval-mozilla-aurora+
Based upon QA's testing, let's land on m-c. Also, a=akeybl for m-a, m-b, m-r, and ESR.
Target Milestone: --- → mozilla13
Hello, Our application works fine with your patched version : ftp://ftp.mozilla.org/pub/firefox/try-builds/cpearce@mozilla.com-4db261dee3f3/try-win32/firefox-10.0.en-US.win32.installer.exe Well done ! Do you know when this patch will be loaded on the offical release version ? Thanks
I have also been having this problem in the current v10 release. I can confirm that the patched version linked in comment 40 works. Great stuff!
confirm patch in comment 40 works!
I also confirm the patch works. Thanks!
(In reply to Chris Pearce (:cpearce) (on paternity leave, don't expect quick response!) from comment #39) > https://hg.mozilla.org/integration/mozilla-inbound/rev/f468e195c899 https://hg.mozilla.org/mozilla-central/rev/f468e195c899
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I see a spike in Linux signatures in Firefox 10 - reports such as https://crash-stats.mozilla.com/report/index/71888852-6e7e-4000-ac45-630eb2120207 mention java applets in the comments.
This was in code which only runs on Windows only, you must be seeing something different.
Marcia : That is probably bug 704249
Verified on 10.0.1 (build1), 10.0.1-ESR (build1), 11.0b2 (build1), 12.0a2 (latest), on Windows XP (with Java SE 6 Update 30) and Windows 7 (with Java SE 6 Update 29). Today's nightly doesn't have the fix, so I'll wait until tomorrow to verify on that.
Verified on latest nightly as well.
Status: RESOLVED → VERIFIED
Blocks: 727692
Problem still exists in 10.0.2 with site www.marktplaats.nl with java applet function quick adding of pictures. Location bar is responsive but other fields are not till I click the location bar.
(In reply to dothesamba from comment #51) > Problem still exists in 10.0.2 with site www.marktplaats.nl with java applet > function quick adding of pictures. Location bar is responsive but other > fields are not till I click the location bar. Please file a new bug with steps to reproduce, and add the qawanted keyword so that we can verify the problem. Thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: