InformAction Forums

Giorgio Maone wrote:

al_9x wrote:I am hoping you will implement the after surrogate.

A "before" surrogate can be easily turned into an "after" surrogate by registering a throw away capturing onload event handle

1. what do you mean by throw away?
2. since you would be registering only when the script is about to be loaded, would an earlier content registration on the doc (such a thing is unlikely, typically content registers on the target itself, but still worth understanding) be invoked first?
3. when before is invoked, will the script element already exist? If yes,
   1. could something be done to allow the load handler to match the target by identity rather than tagName and src? i.e. the surrogate would somehow need to get passed a reference to the matched <script>
   2. could you not attach the load handler with a match by object identity yourself? This would make the after surrogate explicit, smaller and simpler. I was not suggesting that after should be instead of before, but that it should be a first class citizen, hiding the boilerplate of attaching handlers and rematching targets by regex

al_9x wrote:what do you mean by throw away?

al_9x wrote:since you would be registering only when the script is about to be loaded, would an earlier content registration on the doc (such a thing is unlikely, typically content registers on the target itself, but still worth understanding) be invoked first?

al_9x wrote:when before is invoked, will the script element already exist?

al_9x wrote:If yes, could something be done to allow the load handler to match the target by identity rather than tagName and src?

var scripts = document.getElementsByTagName("script"); 
var myScript = scripts[scripts.length - 1]; 
document.addEventListener("load", function(ev) { 
  if (ev.target !== myScript) return;
  ev.currentTarget.removeEventListener(ev.type, arguments.callee, true);
  // do your "after" stuff here
}, true);

al_9x wrote:could you not attach the load handler with a match by object identity yourself? This would make the after surrogate explicit, smaller and simpler.

Giorgio Maone wrote:"Before" ('<') and "After ('>') surrogates added in latest development build 2.1.3rc5.

Test page here.

user_pref("noscript.surrogate.disqus-theme.sources", ">.disqus.com/*/build/themes/t_c4ca4238a0b923820dcc509a6f75849b.js*");
user_pref("noscript.surrogate.disqus-theme.replacement", "DISQUS.dtpl.actions.register('comments.reply.new.onLoadingStart', function() { DISQUS.dtpl.actions.remove('comments.reply.new.onLoadingStart'); DISQUS.dtpl.actions.remove('comments.reply.new.onLoadingEnd');});");

al_9x wrote: Here's the discuss surrogate updated to use the after surrogate

al_9x wrote: But in general, do you think it makes sense for surrogates to be wrapped in functions, which you would invoke, optionally passing something and/or getting some return?

Giorgio Maone wrote:Is it in your opinion OK to include by default (i.e. how likely is it to break sites which use disqus)? For what I could see in this thread, I'd say there's no risk, but I'd like to hear your evaluation.

Giorgio Maone wrote:This sounds like a recipe for disaster: getting one wrapper wrong would risk to open a chrome privilege escalation security hole.

al_9x wrote:the exposure of objects/code created in chrome to content (which would require careful wrapping)?