Cancel request before it is sent

[Nateowami]

Is it possible to cancel an action before the corresponding HTTP request is sent?

From the readme, here's what we have to work with before a message is sent.

gmail.observe.before('send_message', function(url, body, data, xhr){ }

I was thinking it might be possible to cancel the xhr request, but it hasn't even been sent yet.

The use case it to perform a check and prompt the user for confirmation if certain conditions are met.

[josteink]

From what I can tell, we're not really doing any error-checking or catching any exceptions in our XHR intercept code.

Based on that, I would guess that throwing an error in your before-handler will effectively cancel the XHR. Bare in mind, I have not tested this, so I can not guarantee it to work.

With that said, this very issue here seems to confirm it (although in that case, it is reported as a bug): #360

[Nateowami]

Thanks. I may investigate that route. I also just discovered the abort() method on the xhr object. Just experimenting in the console it appeared aborting it before it was sent would keep it from being sent at all (as long as it was open()ed before being abort()ed). It's looking promising

[josteink]

I'm going to assume you figured this one out, and close it for now.

Please re-open if you still need something resolved.

[Nateowami]

I haven't been able to test it thoroughly, but it seems to be working, with no errors logged to the console. Thanks for the help!

[Nateowami]

Unfortunately it appears this is not working. Previously it was stopping requests most of the time. I had occasional issues, but it was hard to differentiate them from a bug I had in my logic. Having just fixed that I stepped through with the debugger and confirmed that the XHR was opened (readyState=1), abort()ed it, and Gmail tried to send the request anyway, with no error in the console. Of note, I do have network issues, but it shouldn't take a network to cancel a network request. My guess is Gmail re open()s the request.

What I'm basically doing is:

gmail.observe.before('send_message', function(url, body, data, xhr){
  if(condition) {
    xhr.abort();
  }
})

[josteink]

Try throwing instead? It's not clean, but I suspect it has a higher chance of success.

[Nateowami]

That's a good idea. Don't know why I didn't think of it. Unfortunately it appears to be having any effect, not even logging the error in the console (not sure that's even possible, but it appears to be happening).

I think I've figured out why I thought it was working before though. When you send an email without a body, Gmail asks you if you're sure. In my testing my prompt would come up first and end up suppressing Gmail's prompt. This made it look like sending was being canceled by me. As soon as you have text in the body though, Gmail no longer prompts, and my prompt ceases to work.

[josteink]

This type of functionality (obstructing Gmail) is not really core to this library, so I'm not sure how much effort we're going to put into it.

That said, if you could put together a minimal proof of concept, I could test and see if I can reproduce. I'm fairly certain throwing in the XHR send method should ruin any chance of success...

[Nateowami]

The ideas isn't really to obstruct Gmail, but to request confirmation before sending the email. In terms of implementation the two tend be about the same. If there were a way to hook into the click event on the send button that would be better, but then I know of no way to detect who the recipients are (necessary in order to decide whether confirmation is necessary).

My project is basically a fork of the gmail-chrome-extension-boilerplate, with about 15 lines of straight-forward JavaScript added, about half of which is logging. Anyway, I think it's very minimal: https://github.com/Nateowami/Blindfold.

[josteink]

I see. Thanks for the clarification and link to your actual production code!

I think a better approach than trying to intercept and postpone the the send-event is to be the one initiating it.

Here's my suggestion. It's a bit more complex, but IMO no where near impossible to do:

• Initiaite Gmail.JS anyway you prefer
• Listen for new compose-windows.
• On the new compose-window event you manipulate the DOM in two ways:
  1. Get a handle for the send-button. Use CSS modifications to hide it.
  2. Create a new button by reusing the existing button's innerHTML (thus preserving locailzation, etc) and inject this next to the hidden button.
• When your button (which is the only one visible) is clicked, run your check, and if everything is OK, manually trigger a click on the hidden send-button via JS (or use the Gmail.JS API to do that for you)
  You can do this by listening for new compose windows, and manipulating their DOM.

How about that?

[JoshTheDerf]

@josteink A cleaner way to handle point 3 might be to simply add an absolutely positioned overlay element to the button's parent.

Or, if you want to get really creative, add a capturing event listener to the send button's parent element that calls event.stopPropagation() if the event target is the send button.
Then when your custom warning is closed, temporarily remove the capturing listener, trigger the button click, and add the event listener back to the parent element.
The advantage being that you only have to know the selector for the send button and don't need to directly modify the DOM.

(I've actually used this method once for a client. Lots of fun.)

There is, of course, still the matter of keybinds. Those can be a problem for people who are used to Mod+Enter being used to add newlines to fields.

[Nateowami]

Thanks for the suggestions. I considered hooking into the click event, but I didn't know how to get the list of email addresses from the To, CC, and BCC fields. Looking at the API a bit more though, I now see there's a recipient_change event that does just that.

I'm a bit confused about the documentation though:

gmail.observe.on('recipient_change', function(match, recipients) {
  console.log('recipients changed', match, recipients);
});

I'm not sure what "match" refers to. From experimenting in the console it appears to be a large DOM element holding everything but the header in the compose dialog. I'm guessing this is in order to find this element in the DOM tree in order to track down which compose dialog it came from?

Actually, with this event handler, maybe I don't even need to intercept a click--just change some styling or something as a warning.

Anyway, thanks so much for the help! Much appreciated. 😄

[josteink]

The match is a compose object or it's a DOM element you can use to construct a compose object with.

Use the compose objects to get the information you need.