Remove defaultPrevented attribut from ol.MapEvent

[fredj]

already defined in parent class:
http://docs.closure-library.googlecode.com/git/class_goog_events_Event.html

[elemoine]

Looks good to me.

[twpayne]

I don't think this is quite right. More detailed comment to follow.

[elemoine]

https://github.com/openlayers/ol3/blob/master/src/ol/map.js#L636 ?

[twpayne]

I don't think this is quite right. More detailled comment to follow.

So, here's why.

There are two separate chains of event handling, which is why a ol.MapEvent currently contains a browser event. The two chains are:

1. The normal browser event handling, which use stopPropagation and preventDefault to stop propagation and suppress the normal browser event handling
2. The map browser event handling, which uses preventDefault to prevent the propagation of a map events further down the interaction stack

For example, you might have multiple interactions that listen for mousedown events, say feature editing and drag panning. In this case, the feature event is on the top of the interaction stack. If the mousedown event hits a feature, the feature editing interaction calls preventDefault to prevent the event being propagated to the drag panning. Without this, editing a feature would also cause the map to pan. Note that these map events are completely separate from the browser event handling.

So, I think this PR as it is will break things. You need to keep two different preventDefaults, one for map events and one for browser events. They can either be in separate objects (as they are at the moment) or be in the same object but have different names (e.g. preventMapDefault / mapDefaultPrevented).

[twpayne]

https://github.com/openlayers/ol3/blob/master/src/ol/map.js#L636 ?

Exactly.

[elemoine]

Tom, I read your comments multiple times but I still fails to understand where the problem is. @fredj's patch just removes a function and a property that are already in the parent class (goog.events.Event). What harm can this cause? Sorry.

[elemoine]

Are you sure you're not mixing up with #791?

[twpayne]

Are you sure you're not mixing up with #791?

Indeed, I am.

So, if I've got it right, this PR is OK, but #791 isn't.

[elemoine]

100% agreement.

[elemoine]

@fredj, please merge this if you agree.