[fix] ensure that the prevent default and stop prop occurs in the correct context

[samccone]

reported here #758 (comment)
introduced in a790fb3

#758 (comment)

[samccone]

hey @zimme and @stid can you let me know if this solves your guy's problem?

[stid]

@samccone yes!, It works!

Thanks a lot!

[samccone]

@stid do my test cases look like yours? or did you have different test criteria. It would be super helpful to see your code that was causing the issues.

[stid]

@samccone I'm not so skilled in javascript testing thus I can't help you with a well coded test. In any case, I have implemented a marionette view that incorporate a form with a standard trigger on the submit buttons. The pattern is exactly the same implemented by http://www.backbonerails.com with the forms as a component (same code).

With the unpatched version I get the first event in my view and after that a standard submit event is triggered and handled by the browser (means the form in submitted and the page reload). With your patch everything works again as expected as only the marionette triggers are executed. As far as I can see, any button tag in a form also if handled via triggers still propagate vents in the 1.2.0 version.

This is the view that add the trigger (it's coffee script):

  class Form.FormWrapper extends  App.Views.Layout
    template: "components/form/form"

    regions:
      formContentRegion: "#form-content-region"

    ui:
      buttonContainer: "ul.inline-list"

    triggers:
      "submit": "form:submit"
      "click [data-form-button='cancel']" : "form:cancel"

Below the html generated by the template, with the button that will trigger the form:submit event and that will continue with event propagation and submit the form via standard http request (no ajax).

<form data-type="edit" enctype="multipart/form-data">
  <div class="panel panel-default">
    <div class="panel-body">
      <filedset>
        <div id="form-content-region"><div><div id="show-user">
  <div class="form-group">
    <label class="control-label">username</label>
    <input class="form-control" type="text" name="user[username]" placeholder="Your username" value="stid">
  </div>
  <div class="form-group">
    <label class="control-label">email</label>
    <input class="form-control" type="text" name="user[email]" placeholder="Your email" value="abc@abc.com">
  </div>
</div></div></div>
        <footer>
          <button class="btn btn-primary" type="submit" data-form-button="primary">Update</button>
        </footer>
      </filedset>
    </div>
  </div>
</form>

A controller intercept the relative view event:

@listenTo @formLayout, "form:submit", @formSubmit

And invoke a specific method that use Backbone.Syphon to serialise the form.

    formSubmit: ->
      data = Backbone.Syphon.serialize @formLayout,
        exclude: ["wpx_image[image]"]

After some other internal logic, I just update the model with the serialized data:

model.save data

Everything work until this point but as the event is still propagated, the browser execute the standard submit just after this specific flow.

Again, problem disappeared with your patch applied and it make sense to me due the event wrong context we discussed in the original issue. This was application wide for me, in every forms and in different layouts / regions.

let me know if I can be of any further help.

[zimme]

Using this commit, doesn't resolve my problem

view

class UsersRowView extends StickitItemView

        tagName: 'tr'
        template: ->
            tpl
        triggers:
            'click #delete': 'click:delete'
            'click #edit': 'click:edit'
            'click #show': 'click:show'

template

<td id="first_name"></td>
<td id="last_name"></td>
<td id="email"></td>
<td><a id="show" class="btn btn-info">Show</a></td>
<td><a id="edit" class="btn btn-info">Edit</a></td>
<td><button id="delete" class="btn btn-danger">Delete</button></td>

My backing controller listens for the trigger events and switches views in application, then default link action is performed by browser and my route is triggered.

[zimme]

Scratch that, It works, using the code from this commit, the amd version wasn't compiled with the changes and that's why it didn't work, patching the amd script i was using manually resulted in this fix solving my problem