Appropriately process messages received via postMessage

[jvilk]

Chrome extensions are fun, aren't they? :)

• Fixes a typo in inject.js (event => evt)
  • This miraculously worked previously because window.event aliases to the last event, and so event === evt.
• Use chrome.runtime instead of chrome.extension for sendMessage/connect.
  • Those two methods aren't even documented for chrome.extension... but it seems they are equivalent (maybe chrome.extension === chrome.runtime internally? either way, it's not guaranteed by the docs)
• Fixes onmessage filtering to ignore irrelevant messages.
  • evt.source === window trivially passes for any messages sent from the window context.
  • For example, Facebook.com spams string messages of the form "setImmediate $0.384240" at a fast rate as you move your mouse on the page. You were previously sending those on via sendMessage.
    • The Batarang didn't see those Facebook messages, though, because sendMessage takes an optional string (the target extension ID) as its first parameter. So whenever chrome.extension.sendMessage saw one of those "setImmediate $0.324324" messages, it would think you were trying to send a message to an extension with that ID!
  • evt.origin doesn't work for this, btw, as the origin for your messages will be e.g. facebook.com if you open the Batarang on Facebook.

Hope this helps you out. :)

[jvilk]

Oops, looks like I forgot to fix the mock objects, leading to Travis failures! I can fix that in a couple of hours.

[SomeKittens]

Thanks for the PR (and apologies for not getting to this sooner). Can you rebase this into one commit following our commit rules?

[jvilk]

Sure. I'll do that tonight.

[SomeKittens]

Awesome, thanks again!

[jvilk]

OK, I've squashed and changed the commit to follow your commit rules. @SomeKittens, you should link to the official AngularJS contributing guide in the Batarang's CONTRIBUTING.md! Had it been linked / mentioned before, I would have opened the PR in the appropriate format from the start. :-)

If you want, I can open up a PR to do that for you, but it looks like that doc could use some loving. Looks like @btford was a bit lazy when he put it together; maybe we should give him more work to do. :wink:

[jvilk]

Also, the build process for the Batarang appears to update files in the dist folder. I did not include these in the PR, despite them being under version control. Perhaps you should mention what to do about those in the contributing guide, as well.

[SomeKittens]

Hmm, didn't realize our CONTRIBUTING was out of date. Wouldn't it be nice if you could symlink across GitHub?

Not including the dist files is fine. Us contributors are still on the fence about it. (and as you say, it'll all be overridden by builds anyway.

I'm halfway through debugging https://github.com/angular/angular-hint/issues/88 so my index is dirty. Once I clear that up I'll be able to bring this in. Pleasure doing business with you.

[SomeKittens]

Hello again! Serious apologies for not getting to this sooner.

We do emit events that don't have the severity property (see https://github.com/angular/angular-hint/blob/master/src/modules/scopes.js#L42 ), so this will result in false negatives. (That's our documentation fail - working on it...)

[jvilk]

@SomeKittens ah OK, I thought I grepped for all emit calls.

Which fix would you prefer?

• I alter your event objects to have a single standard property that indicates that it's a Batarang event (e.g. evt.__fromBatarang = true) (this is the solution I prefer in my projects.)
• I alter the event object check to check for all event objects as they currently are.

[SomeKittens]

I'd prefer __fromBatarang as that's very clear to anyone reading it what it means.

[jvilk]

I looked into this, @SomeKittens, and it looks like there's no problem (correct me if I'm misunderstanding the source code):

• hint is an EventEmitter2 object
• hint.emit emits an event on EventEmitter2
• Your hint.js is the only part of the program I can find that forwards any emitted events on hint via postMessage
  • See the documentation for EventEmitter2.onAny
  • Note: onAny blindly forwards all arguments to emit past the first one, so in your codebase, the first argument is always the data and the second is the severity.

Thus, I believe every postMessage event has a severity property.

I did modify the commit to add the explicit __fromBatarang property, though, as I believe that is a clearer way of identifying your messages.

[SomeKittens]

It'll be there - it just might be falsy.

consensus is __fromBatarang, will try and get to this tonight.

[jvilk]

poke

[SomeKittens]

Landed in 56c3ad7162c9edef8f6cddb578a48c80977faaed