disqus reply.html iframe placeholder out of place

[al_9x]

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

A few questions about how it would work:

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

[Giorgio Maone]

what do you mean by throw away?

That you deregister it as soon as it's called.

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?

The invocation order should be undefined by DOM specification, but in practice Firefox calls listeners on the same target in registration order.
So yes, an early registration on the doc would be called first.

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

Yes.

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

Code: Select all

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);

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

Yes, that's probably a good idea, mainly because of the precedence thing (the boilerplate wouldn't be that much, as you can see above).
If done implicitly by NoScript, the event handler can probably be registered at a higher level (docShell?) and be called first in capture mode.

[Giorgio Maone]

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

Test page here.

[al_9x]

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

Test page here.

looks good, thanks. Here's the discuss surrogate updated to use the after surrogate:

Code: Select all

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');});");

One minor inconvenience I noticed is that since these surrogates are themselves injected as script elements, the last script in the doc at the time of invocation is the surrogate and not the matched script. There will probably be no need to get at the script at all, so this is likely an non-issue.

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? This could also enable the sharing of utility code among surrogates, e.g. a lazily instantiated recursive proxy.

[Giorgio Maone]

Here's the discuss surrogate updated to use the after surrogate

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.

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?

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

[al_9x]

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.

This particular script (t_c4ca4238a0b923820dcc509a6f75849b.js) is evidently a component of a fairly common disqus theme. At the moment the surrogate definitely works to keep the placeholder in the right place, and is tied to only that theme. It unregisters two events, comments.reply.new.onLoadingStart and comments.reply.new.onLoadingEnd.

All they do is show a loading indicator. LoadingEnd is an inverse of LoadingStart, calling them both is the same as not calling either. Since this is a theme component, designed presumably to only modify the look and feel, I am guessing that nothing too significant will ever be added to these events, and their inverse relationship should continue. It seems safe to me.

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

Could you please expand on this, I'd like to better understand this possibility. Is the danger in the adding of such functions to the shared global namespace (even if temporarily) and/or the exposure of objects/code created in chrome to content (which would require careful wrapping)?

[Giorgio Maone]

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

This one.

[al_9x]

Here's another example use case:

MS Office blogs use Gigya for comments. A Gigya script uses window.globalStorage without checking for null so when dom storage is disabled, comments don't show.

Code: Select all

user_pref("noscript.surrogate.gigya_storage.sources", "<cdn.gigya.com/js/socialize.js");
user_pref("noscript.surrogate.gigya_storage.replacement", "if (!globalStorage) Object.defineProperty(window, 'globalStorage', {value: function() {var p = Proxy.createFunction({get: function(receiver, name) name in Object.prototype ? Object.prototype[name] : p, set: function() true}, function() p); return p;}()});");

This is not necessarily for inclusion, I didn't test extensively how well it works with with this dummy globalStorage, but the comments do show.