bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

isComposing is not part of mozView protocol but called through mozView pointer

RESOLVED FIXED

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Josh Aas, Assigned: masayuki)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
This is a regression from bug 355971.

/Users/josh/src/mozilla/ff_cocoa_debug/mozilla/widget/src/cocoa/nsChildView.mm:1894:
warning: '-isComposing' not found in protocol(s)
(Reporter)

Comment 1

12 years ago
Created attachment 243622 [details] [diff] [review]
fix v1.0

masayuki - do you know of a way to fix your bug without having to do this? If not, that is OK.
Attachment #243622 - Flags: review?(masayuki)

Comment 2

12 years ago
Can more than one view be in composition mode at the same time? 

If not, why not make it a class method of ChildView, store the state in a static boolean, and just call [ChildView isComposing]?

If you add the method to the protocol, you need to add it to nsNativeScrollbar and Camino as well.

Comment 3

12 years ago
Another idea, if this method only really makes sense on ChildView (and not nsNativeScrollbar or random custom views implementing mozView), would be to use respondsToSelector:@selector(isComposing) instead, and make it a informal protocol method.
Comment on attachment 243622 [details] [diff] [review]
fix v1.0

(In reply to comment #2)
> Can more than one view be in composition mode at the same time? 
>
> If not, why not make it a class method of ChildView, store the state in a
> static boolean, and just call [ChildView isComposing]?

The current trunk code (especially in nsIMEStateManager) assumes that there is only one transaction on Gecko. Because if focus is changing in Gecko, the last IME transaction is committed by nsIKBStateControl::ResetInputState. I think that the ResetInputState is working fine, the idea of changing to static is good. But the ResetInputState doesn't work fine, now.(I confirmed that on 10.4) Of course, we should fix it before 1.9 final. Therefore, I think that this is enough now.
Attachment #243622 - Flags: review?(masayuki) → review+
FYI:

We discussed to implement of nsIKBStateControl on Cocoa in Bugzilla-jp.
We may have a chance of changing to static variable before 1.9 final.

Comment 6

12 years ago
I really think it's better to have it as an informal protocol method, rather than explicitly adding it to the mozView @protocol, even short-term.  Think of a protocol as an interface, you shouldn't lightly add methods that are going to be removed soon.
this bug will be fixed by bug 358899. the members are removed by the patch. (they will be static.)
Assignee: joshmoz → masayuki
Depends on: 358899
(Reporter)

Comment 8

12 years ago
excellent!
-> FIXED by bug 358899
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.