Closed Bug 481510 Opened 15 years ago Closed 2 years ago

Clean up event handling

Categories

(Core :: DOM: Events, defect, P5)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: smaug, Assigned: smaug)

References

(Depends on 1 open bug)

Details

We should either have proper split between nsEvent and nsDOMEvent, 
or we should merge them together.

I prefer split, because nsEvents are used for many other
things than just DOM Events.
Currently nsEvent has many things which belong to nsDOMEvent, for example
target/currentTarget/originalTarget. nsEvent has also some flags which don't
make sense elsewhere than in DOM: capturing/bubbling, propagation stopped, "no content dispatch", trusted.
On the other hand nsEvent has few things which aren't really about DOM
but something lower level, like widget in nsGUIEvent or nativeMsg (which is a
pointer to some OS level message).
And with multiprocess/threads setup only nsDOMEvents should propagate
to chrome event listener. They would be heap objects, nsEvents stack-only.
The event system looks like it could need some refactoring, the number of steps you need to edit in order to create a an nsEvent and nsDOMEvent looks insane (in the lack of a better word).  

We have nice IDL desciptions of the nsDOMEvents, we could create an IDL for the nsEvents too and extend the IDL compiler to autogenerate what ever is needed to transport and manage both types of events, special tags could be used to indicate "cross system" events (i.e. events that need to propagate both as nsEvents and nsDOMEvents).  

About the relationship between the two event types, then ofcause it would be nicer to have only one type, but on the other hand it sounds like they are not exactly serving the same purpose.  The point in the code where it seems to matter most for the "user" (e.g. programmers) of the system is at the point of sending the event, as we at the receiving end probably expect one or the other type - so it migth be an idea to have pure nsEvents and pure nsDOMEvents, and then create a cross system event that is both (or looks like it is both when it is sent, might be a dummy interface that hides that it is infact two events - again something that could be generated by an IDL compiler)....

Could this be a topic for discussion at the "All hands" meeting next month?  It might be benificial to discuss this in front of a whiteboard :)
(In reply to comment #3)
>we could create an IDL for the
> nsEvents too
No. nsEvent is lower level event and should be a stack object only.

> and extend the IDL compiler to autogenerate what ever is needed to
> transport and manage both types of events, special tags could be used to
> indicate "cross system" events (i.e. events that need to propagate both as
> nsEvents and nsDOMEvents). 
When nsEvent needs a corresponding nsDOMEvent, nsDOMEvent is created just
before dispatching it to DOM.

> About the relationship between the two event types, then ofcause it would be
> nicer to have only one type, but on the other hand it sounds like they are not
> exactly serving the same purpose.
Right. They are pretty different things. nsEvent handles events
coming from OS and nsDOMEvent is for DOM (as specified by W3C).

>  The point in the code where it seems to
> matter most for the "user" (e.g. programmers) of the system is at the point of
> sending the event, as we at the receiving end probably expect one or the other
> type - so it migth be an idea to have pure nsEvents and pure nsDOMEvents, and
> then create a cross system event that is both (or looks like it is both when it
> is sent, might be a dummy interface that hides that it is infact two events -
> again something that could be generated by an IDL compiler)....
I would expect that most of the time developers would use nsDOMEvents.
Only events coming from widget level should be nsEvents.


> Could this be a topic for discussion at the "All hands" meeting next month?  It
> might be benificial to discuss this in front of a whiteboard :)
Bah. If I'm very lucky I have this fixed before all hands :p
(In reply to comment #4)
> (In reply to comment #3)
> >we could create an IDL for the
> > nsEvents too
> No. nsEvent is lower level event and should be a stack object only.

Why do you see a connection between IDL and stack?

> 
> > and extend the IDL compiler to autogenerate what ever is needed to
> > transport and manage both types of events, special tags could be used to
> > indicate "cross system" events (i.e. events that need to propagate both as
> > nsEvents and nsDOMEvents). 
> When nsEvent needs a corresponding nsDOMEvent, nsDOMEvent is created just
> before dispatching it to DOM.

Yes, but you might be missing my point - that nsEvent has knowlegde about nsDOMEvent that it does not need - like mentioned by smaug, these could be removed from the vanilla nsEvent if we made a special type (fictive or real) that was only used when an event needed to be both what we know today as nsEvent and nsDOMEvent.

> 
> >  The point in the code where it seems to
> > matter most for the "user" (e.g. programmers) of the system is at the point of
> > sending the event, as we at the receiving end probably expect one or the other
> > type - so it migth be an idea to have pure nsEvents and pure nsDOMEvents, and
> > then create a cross system event that is both (or looks like it is both when it
> > is sent, might be a dummy interface that hides that it is infact two events -
> > again something that could be generated by an IDL compiler)....
> I would expect that most of the time developers would use nsDOMEvents.
> Only events coming from widget level should be nsEvents.

In that case you would use the specialized events, the commen type is only supposed to be used when you need both, could be temporary for backwards compatibility, I don't know every single event and its use in all of the code :)
 
> 
> > Could this be a topic for discussion at the "All hands" meeting next month?  It
> > might be benificial to discuss this in front of a whiteboard :)
> Bah. If I'm very lucky I have this fixed before all hands :p

*LOL* I think it depends on what it is you think you will be fixing :)
Depends on: 495983, 496000
Depends on: 496102
Depends on: 496317
Depends on: 496567
Depends on: 497178
Depends on: 662335
Priority: -- → P5

The current setup works quite well with multiprocess setup. No need to do anything here.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.