getFrecentSites api #46
Conversation
change currentEngine to getCurrentEngine()
* 'WebIDL' of github.com:mozilla/newtab-dev: fix object reference for getCurrentEngine disable _storeEngine temporarily
* 'WebIDL' of github.com:mozilla/newtab-dev: restore __storeEngine Fix getCurrentEngine (add yield)
|
At first glance, this looks good to me. |
| }); | ||
| }, | ||
|
|
||
| _send(data) { |
There was a problem hiding this comment.
So, question I have here (maybe also for @oyiptong)... what's the advantage of using WebChannel.jsm over PromiseMessage? I see that WebChannel.js integrates with the security manager, which is kinda need. Would love to coordindate with @vladikoff a bit here to figure out what would be the best approach - or perhaps y'all already figured all that out in my absence, which would be great (I hate thinking!:)).
I could be mistaken, but the thing that worries me about WebChannel.jsm is that we are again sending CustomEvents back to Web Content? Or is that not what is happening in WebChannel.jsm. The idea behind using the IDL is that we no longer send custom events and allow for more sophisticated APIs that don't rely solely on events being sent to/from content (while benefiting from the WebIDL binding to perform the per-origin security check).
There was a problem hiding this comment.
You probably won't need WebChannel.jsm because it solves the problem of communication between tabs and the browser. You already have that figured out.
I could be mistaken, but the thing that worries me about WebChannel.jsm is that we are again sending CustomEvents back to Web Content? Or is that not what is happening in WebChannel.jsm. The idea behind using the IDL is that we no longer send custom events and allow for more sophisticated APIs that don't rely solely on events being sent to/from content (while benefiting from the WebIDL binding to perform the per-origin security check).
Exactly, with WebIDL you should not need it. That's my response at the first glance, I don't have the knowledge of all your plans here though :)
|
We're not using WebIDL for now for the remote newtab page for the following reasons:
When our API surface becomes more solid, we may consider using WebIDL. But it looks like it doesn't buy us much for now. |
It's working! Needs cleanup though