Steven Michaud [:smichaud] (Retired) Reporter
	Description • 18 years ago

This version fixes a number of major problems, some of which are
regressions that appeared in JEP 0.9.5+e.

	Mark Mentovai Assignee
	Comment 2 • 18 years ago

Comment on attachment 230956 [details]
Change log for JEP 0.9.5+g

I'll test this.

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 3 • 18 years ago

> I'll test this.

Mark, any news?

	Mark Mentovai Assignee
	Comment 4 • 18 years ago

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?

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 5 • 18 years ago

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.)

	Mark Mentovai Assignee
	Comment 6 • 18 years ago

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 Michaud [:smichaud] (Retired) Reporter
	Comment 7 • 18 years ago

> 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 :-)

	Mike Pinkerton (not reading bugmail)
	Comment 8 • 18 years ago

Comment on attachment 230956 [details]
Change log for JEP 0.9.5+g

rs=pink

	Mark Mentovai Assignee
	Comment 9 • 18 years ago

Checked in on the trunk.

	Mark Mentovai Assignee
	Comment 10 • 18 years ago

Comment on attachment 230956 [details]
Change log for JEP 0.9.5+g

This fixes some very serious blockers.

	Mark Mentovai Assignee
	Comment 11 • 18 years ago

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

	Mark Mentovai Assignee
	Comment 12 • 18 years ago

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

	David Baron :dbaron:
	Comment 13 • 18 years ago

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.

	Mark Mentovai Assignee
	Comment 14 • 18 years ago

Checked in on MOZILLA_1_8_BRANCH before 1.8.1b2.

	Daniel Veditz [:dveditz]
	Comment 15 • 18 years ago

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 1.5.0.8?

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 16 • 18 years ago

> 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+).

	Mark Mentovai Assignee
	Comment 17 • 18 years ago

> 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.

	Steven Michaud [:smichaud] (Retired) Reporter
	Comment 18 • 18 years ago

> 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 1.5.0.5 (which bundles JEP 0.9.5+f+).

	Daniel Veditz [:dveditz]
	Comment 19 • 18 years ago

Mark: given comment 18 do you still want this on 1.8.0.7 and think it's safe enough?

	Mark Mentovai Assignee
	Comment 20 • 18 years ago

#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.

	Daniel Veditz [:dveditz]
	Comment 21 • 18 years ago

Comment on attachment 230956 [details]
Change log for JEP 0.9.5+g

Land away: approved for 1.8.0 branch, a=dveditz

	Mark Mentovai Assignee
	Comment 22 • 18 years ago

Checked in on MOZILLA_1_8_0_BRANCH for 1.8.0.7.