Java applet causes text entry fields to become semi-unresponsive

VERIFIED FIXED in Firefox 10

Status

()

Core
Widget: Win32
--
major
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Eric Tam [krazywrath], Assigned: cpearce)

Tracking

(4 keywords)

10 Branch
mozilla13
All
Windows 7
regression, relnote, verified-aurora, verified-beta
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(firefox10+ verified, firefox11+ verified, firefox12+ verified, firefox13 verified, firefox-esr1010+ verified)

Details

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago
See Also: → bug 382906
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
tracking-firefox10: --- → ?
tracking-firefox11: --- → ?
tracking-firefox12: --- → ?
Component: Java-Implemented Plugins → Plug-ins
Ever confirmed: true
Keywords: regression
Hardware: x86_64 → All

Comment 2

6 years ago
(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
tracking-firefox11: ? → +
tracking-firefox12: ? → +

Comment 3

6 years ago
Please re-nominate for FF10 if it ends up being affected.
tracking-firefox10: ? → -
(Reporter)

Comment 4

6 years ago
(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.

Comment 5

6 years ago
(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.
tracking-firefox10: - → +
Assignee: blackconnect → nobody
QA Contact: blackconnect → plugins
Duplicate of this bug: 723675
Duplicate of this bug: 723682

Updated

6 years ago
Blocks: 699885

Updated

6 years ago
Duplicate of this bug: 723046

Comment 9

6 years ago
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

Comment 10

6 years ago
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.
Duplicate of this bug: 723891

Comment 12

6 years ago
merge with 713607
Duplicate of this bug: 713607
Duplicate of this bug: 724382
Duplicate of this bug: 724381

Updated

6 years ago
status-firefox-esr10: --- → affected

Comment 16

6 years ago
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.

Comment 17

6 years ago
I tried it. Doesn't work.

Comment 18

6 years ago
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

Comment 20

6 years ago
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!

Updated

6 years ago
Version: 12 Branch → 10 Branch

Comment 22

6 years ago
(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?

Comment 24

6 years ago
(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

Comment 25

6 years ago
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)

Comment 26

6 years ago
(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.

Updated

6 years ago
Component: DOM: Core & HTML → Widget: Win32
QA Contact: general → win32
(Assignee)

Comment 27

6 years ago
Well fix this by backing out bea7ecf9084e.
(Assignee)

Comment 28

6 years ago
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.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #595168 - Flags: review+
(Assignee)

Comment 29

6 years ago
Created attachment 595169 [details] [diff] [review]
Patch: backout bea7ecf9084e from m-c

Backout bea7ecf9084e from m-c.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=451c593d557b
Attachment #595169 - Flags: review+
(Assignee)

Comment 30

6 years ago
Created attachment 595175 [details] [diff] [review]
Patch: backout bea7ecf9084e from m-b

Backout from beta.
Try: https://tbpl.mozilla.org/?tree=Try&rev=a0aaa91b06ef
Attachment #595175 - Flags: review+
(Assignee)

Comment 31

6 years ago
Created attachment 595206 [details] [diff] [review]
Patch: backout bea7ecf9084e from m-a

Backout bea7ecf9084e from m-a
https://tbpl.mozilla.org/?tree=Try&rev=1a6a08aa1078
Attachment #595206 - Flags: review+
(Assignee)

Comment 32

6 years ago
Created attachment 595258 [details] [diff] [review]
Patch: backout bea7ecf9084e from esr10
Attachment #595258 - 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.

Updated

6 years ago
Attachment #595168 - Flags: approval-mozilla-release+

Updated

6 years ago
Attachment #595175 - Flags: approval-mozilla-beta+

Updated

6 years ago
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.
(Assignee)

Comment 35

6 years ago
https://hg.mozilla.org/releases/mozilla-release/rev/18ce5e304e97
(Assignee)

Comment 36

6 years ago
https://hg.mozilla.org/releases/mozilla-esr10/rev/7d38a883abb8
(Assignee)

Comment 37

6 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/c0feb8e404a0
(Assignee)

Comment 38

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/87c39b5f821c
(Assignee)

Comment 39

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/f468e195c899

Updated

6 years ago
status-firefox-esr10: affected → .1-fixed
status-firefox10: --- → fixed
status-firefox11: --- → fixed
status-firefox12: --- → fixed

Updated

6 years ago
Target Milestone: --- → mozilla13

Comment 40

6 years ago
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

Comment 41

6 years ago
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!

Comment 42

6 years ago
confirm patch in comment 40 works!

Comment 43

6 years ago
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
Last Resolved: 6 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.
(Assignee)

Comment 46

6 years ago
This was in code which only runs on Windows only, you must be seeing something different.
Marcia : That is probably bug 704249
tracking-firefox-esr10: --- → .1+
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.
Keywords: verified-aurora, verified-beta

Updated

6 years ago
status-firefox11: fixed → verified
status-firefox12: fixed → verified

Updated

6 years ago
status-firefox-esr10: .1-fixed → .1-verified
status-firefox10: fixed → verified
Verified on latest nightly as well.

Updated

6 years ago
Duplicate of this bug: 725896

Updated

6 years ago
Status: RESOLVED → VERIFIED
status-firefox13: --- → verified

Updated

6 years ago
status-firefox-esr10: .1-verified → verified
tracking-firefox-esr10: .1+ → 10+

Updated

6 years ago
Blocks: 727692

Comment 51

6 years ago
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!
See Also: → bug 868005
You need to log in before you can comment on or make changes to this bug.