Closed Bug 346156 Opened 14 years ago Closed 14 years ago
New version of JEP (0
.9 .5+g), please land on trunk and branches
This version fixes a number of major problems, some of which are regressions that appeared in JEP 0.9.5+e.
> I'll test this. Mark, any news?
I've tested this out with the current 1.8 branch source, augmented to log interesting events. It's a direct fix for these bugs: - Bug 344153 - NS_KEY_DOWN and NS_KEY_UP events stop in a window that has hosted a Java applet - Bug 344006 - JEP leaves wrong TSM document set, can prevent text input - Bug 344701 comment 6 et seq. - JEP not redispatching TSM events to some windows It also has the bug 344249 fix already present in 0.9.5+f+. It doesn't fix bug 344150, but my patch in bug 344006 does. There are still some outstanding issues here: - After loading Java in a window, key equivalents for menu items are not processed as menu events. In most cases, we have key event handlers that pick these up, however a result of this is that menu titles no longer blink when using a key equivalent, and some key equivalents no longer work. Command-comma (preferences) and command-option-H (hide others) no longer function, as we have not bound these to any keys in the application but instead rely on other mechanisms to associate the keystrokes with menu items. Steven and I discussed this, and possible solutions, after +f+ was released. - Dead key keystrokes are not handled properly in any window after Java has loaded. This was reported in bug 344153 comment 4. I debugged this problem and found that we weren't receiving the expected kUpdateActiveInputArea Apple event during input method input for a dead key. HandleAETSM is refusing redispatch because of the check at Handlers.m:2250, whose comments indicate it was introduced to fix bug 313807. The input method (as in defaultInputMethod) is 0 in this case, although both GetTextServiceLanguage and GetDefaultInputMethod succeeded. But I don't see why HandleAETSM needs to make this check anyway. Steven, what are the chances of getting a +g+ follow-up to address these problems?
I'm not going to be able to tackle either the "key equivalents for menu items" or "dead key keystrokes" problem right away. I'll have less time to spend on the Java Embedding Plugin over the next couple of months, and I won't have any time at all next week (I'll be away from my computer). Both problems sound like they'll be a lot of work to handle, and in fact they might not be fixable (or fully fixable). I certainly want to deal with them, but I don't consider them either of them to be urgent. If all goes well, I'll deal with them in a JEP 0.9.5+h or 0.9.5+i. Several of the fixes that JEP 0.9.5+g contains are a lot more urgent than these two problems. I suggest getting it on the trunk and 1.8.0 branch right away, and on the 1.8 branch reasonably soon. (I don't know if there's still enough time to get JEP 0.9.5+g into Firefox 2.0 Beta 2.)
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g r+ for landing 0.9.5+g as it fixes the bugs it claims to fix and doesn't introduce any new regressions. I was really hoping we could get fixes for the other issues into Firefox 2, as they are user-visible. The menu-command thing makes the fix for bug 50590 ineffective after Java loads and prevents command-comma from working. The dead-key thing, while not new, has been reported to me two or three times over the past couple of weeks. Steven, if you don't have time to work on the JEP soon, would you mind if I took a look at them some time before Firefox 2?
> Steven, if you don't have time to work on the JEP soon, would you > mind if I took a look at them some time before Firefox 2? I assume you're talking about the Firefox 2 release, and not any of the betas. Is that supposed to be about a month away? Go ahead. But time is short, and for the next couple of weeks you'll be on your own. And any changes you make on your own will be a _lot_ riskier than anything I've done for at least the last year :-)
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g rs=pink
Attachment #230956 - Flags: superreview?(mikepinkerton) → superreview+
Checked in on the trunk.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g This fixes some very serious blockers.
Attachment #230956 - Flags: approval1.8.1?
Spun off the following bugs reported in comment 4: - Bug 340739 - Key equivalents not processed as menu events after loading Java - Bug 340741 - Dead keys not handled after loading Java in a window
No longer blocks: 344249
Oops. I really meant: Spun off the following bugs reported in comment 4: - Bug 347039 - Key equivalents not processed as menu events after loading Java - Bug 347041 - Dead keys not handled after loading Java in a window
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and add the keyword fixed1.8.1 once you have done so.
Attachment #230956 - Flags: approval1.8.1? → approval1.8.1+
Checked in on MOZILLA_1_8_BRANCH before 1.8.1b2.
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g The 1.8.0 branch doesn't have a fix for bug 344701, do we still need this JEP? We're on a tight schedule and the last one caused a little heartburn. Is there anything in here that can't wait until 18.104.22.168?
> the last one caused a little heartburn Actually, all the recently discovered JEP regressions were introduced in JEP 0.9.5+e or older versions. JEP 0.9.5+e was landed on the 1.8.0 branch on 2006-06-13. It's just that the problems were discovered more recently. > do we still need this JEP? I think items #1 and #3 on the change log are pretty important (#2 was already fixed in JEP 0.9.5+f+).
> I think items #1 and #3 on the change log are pretty important (#2 was > already fixed in JEP 0.9.5+f+). Someone will correct me if I'm wrong, but #1's not a problem on the 1.8.0 branch. #3 probably does fix some activation problems, but bug 344006, the primary motivator, isn't a problem on the 1.8.0 branch either.
> Someone will correct me if I'm wrong, but #1's not a problem on the > 1.8.0 branch. Problem #1 effects IME input on all Carbon-based Mozilla.org browsers, and all versions of the JEP. > but bug 344006, the primary motivator, isn't a problem on the 1.8.0 > branch either Not so. I just reproduced the activation problem described in bug 344006 comment #0 with FF 22.214.171.124 (which bundles JEP 0.9.5+f+).
Mark: given comment 18 do you still want this on 126.96.36.199 and think it's safe enough?
#1's pretty nasty - if it is indeed reproducible on 1.8.0, then I think that alone is reason enough to take the new JEP.
Comment on attachment 230956 [details] Change log for JEP 0.9.5+g Land away: approved for 1.8.0 branch, a=dveditz
Attachment #230956 - Flags: approval188.8.131.52? → approval184.108.40.206+
Checked in on MOZILLA_1_8_0_BRANCH for 220.127.116.11.
You need to log in before you can comment on or make changes to this bug.