Closed Bug 26269 Opened 21 years ago Closed 15 years ago

Mac: need to generate events for modifier key events

Categories

(Core Graveyard :: Widget: Mac, enhancement, P3)

PowerPC
macOS
enhancement

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8.1beta2

People

(Reporter: Brade, Assigned: mark)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1, platform-parity)

Attachments

(2 files)

Split off from bug 6649: the mac event handler doesn't generate any key events 
when just the modifier keys are pressed.

We should generate Key Down, Key Press, and Key Up events for the following keys:
 * shift
 * alt
 * command
 * control
accept this so I don't get nagged ;-)
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: M20
Keywords: pp
Summary: [pp]Mac: need to generate events for modifier key events → Mac: need to generate events for modifier key events
Target Milestone: M20 → Future
adding help wanted keyword
Keywords: helpwanted
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Blocks: 41748
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Any more recent comments on if we're ever going to do this or can we just close 
it as WONTFIX?
We really should fix this (rather than marking it wontfix); right now, I'm
waiting for joki to do another pass (or 2?) on the key event spec for the w3c.
I'm guessing that we'll need to do a bit of work on the mac-side to conform to
the spec (including this piece of work and some others).
QA contact updated
QA Contact: gerardok → madhur
QA Contact: madhur → rakeshmishra
is bug 166238 dupe of this one? in the description, `mac event handler'
is mentioned. Does it refer to some sort of special event handler or
event handler in Macintosh?
This is a Mac-specific bug.  Fixing this bug correctly would include
combinations.  At this point in time, there are no plans to fix this bug.

The other bug sounds specific to Linux or Windows.
OS: Mac System 8.5 → All
QA Contact: rakeshmishra → trix
OS: All → MacOS X
Attached patch v1Splinter Review
Platform parity...
Assignee: brade → mark
Attachment #230903 - Flags: review?(joshmoz)
Attachment #230903 - Flags: review?(joshmoz) → review+
A few notes:
 * The original comment had a typo for the bug number.  This bug was a spinoff from bug 6449.
 * The Windows-specific version of this issue is bug 26262.
 * Bug 26262 might have a test case which would work for this bug.
Attachment #230903 - Flags: superreview?(mikepinkerton)
Attached file Testcase
Thanks, Kathleen.  I meant to attach the testcase I had been using...

The patch here implements the behavior I believe to be the current correct behavior: only NS_KEY_UP and NS_KEY_DOWN for modifiers, and I'm only supporting the four modifiers we support elsewhere.  Windows gets this wrong (in my opinion) by continuing to send NS_KEY_DOWN events for modifiers that are held down (autokey events), but it does that for regular keypresses too.  Linux gets this wrong by setting the modifier fields (like event.shiftKey) to the state of the key before the up/down action that triggered the event.  I'm sure there are other bugs (or not) on those behaviors.  I didn't feel compelled to match Windows on the autokey issue (where I think it's wrong anyway) because we don't match them there for non-modifier autokeys either.  We rock!
Comment on attachment 230903 [details] [diff] [review]
v1

sr=pink
Attachment #230903 - Flags: superreview?(mikepinkerton) → superreview+
Keywords: helpwanted
Checkified in on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
mark, I don't think your change will build with a debug build, because you have remove the result (a nsresult), but this code still remains:

        NS_ASSERTION(NS_SUCCEEDED(result), "cannot DispatchWindowEvent");       
Seth, you caught me with my pants down.  I usually develop in widget with "g" builds (debugging symbols but no assertions or warnings) to keep the screen clear for my own informative output.  I've removed the assertions, which were actually entirely bogus.  Thanks.
> I've removed the assertions

thanks for fixing that.  I'm able to build again!
Comment on attachment 230903 [details] [diff] [review]
v1

Easy platform parity fix
Attachment #230903 - Flags: approval1.8.1?
Comment on attachment 230903 [details] [diff] [review]
v1

approved by schrep for drivers
Attachment #230903 - Flags: approval1.8.1? → approval1.8.1+
Checked in on MOZILLA_1_8_BRANCH for 1.8.1b2.
Component: Event Handling → Widget: Mac
Keywords: fixed1.8.1
QA Contact: trix → mac
Target Milestone: Future → mozilla1.8.1beta2
Version: Trunk → 1.8 Branch
Product: Core → Core Graveyard
Version: 1.8 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.