Simplify constructor of WidgetCommandEvent

ASSIGNED
Assigned to

Status

()

Core
Event Handling
ASSIGNED
4 years ago
4 years ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Comment hidden (empty)
Created attachment 8374716 [details] [diff] [review]
Patch

This is used only for onAppCommand...

InitWithAppCommand() or SetAppCommand() is better?
Attachment #8374716 - Flags: review?(bugs)

Comment 2

4 years ago
Comment on attachment 8374716 [details] [diff] [review]
Patch

This feels odd.
Perhaps InitAppCommand should take two nsIAtoms, the one for userType and the one
for command.

Or just let the ctor to take command but hide nsGkAtoms::onAppCommand in the
implementation of ctor, and don't have InitAppCommand at all.
Attachment #8374716 - Flags: review?(bugs) → review-
(In reply to Olli Pettay [:smaug] from comment #2)
> Perhaps InitAppCommand should take two nsIAtoms, the one for userType and
> the one for command.

I think that if we'll take this approach, the name should be InitCommand(). However, it looks like redundant all callers to pass nsGkAtoms::onAppCommand for the userType. Therefore, I added InitAppCommand() only for onAppCommand.

Don't you mind the redundancy?

> Or just let the ctor to take command but hide nsGkAtoms::onAppCommand in the
> implementation of ctor, and don't have InitAppCommand at all.

I think that this is not good for the case of document.createEvent("commandevent").
Flags: needinfo?(bugs)

Comment 4

4 years ago
How is .createEvent case relevant here?

Could we actually get rid of gecko only CommandEvent, and just make FF UI to use the better
keyboard event support we have these days.
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.