<div dir="ltr"><div>Thanks for the detailed info! I myself have authored some addons, so I know about addon code and debugging them. How do I check if the addon has explicitly opted out to use this shim or not?<br><br></div>Regards<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 25, 2016 at 9:16 PM, Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry - didn't mean to sling jargon at you. Happy to clear this up:<br>
<br>
Add-ons have traditionally had no problems directly accessing web<br>
content "synchronously", which means "right away before doing anything<br>
else".<br>
<br>
With content split out into its own process, we have the main process<br>
and content process acting somewhat independently of one another. They<br>
run their own event loops, they do their own garbage and cycle<br>
collection, etc.<br>
<br>
This means that in order to access web content "synchronously" in the<br>
multi-process model, we have to tell the content process to stop<br>
whatever it's doing (which can sometimes take some time), respond to our<br>
command, and return a result. There's some complexity there that I'm<br>
glossing over, but that's essentially the model.<br>
<br>
The problem with that is while we're waiting for the content process to<br>
stop what it's doing, because we need the answer synchronously ("right<br>
away before doing anything else"), that means that the main thread in<br>
the parent process is blocked waiting for the reply from the content<br>
process. That makes it unresponsive, because it cannot respond to user<br>
events when it's blocked.<br>
<br>
Built-in Firefox code has been re-engineered over the past few years to<br>
not access web content synchronously anymore - but older add-ons still<br>
sometimes use the old model. Instead of breaking those add-ons, we<br>
created this "shim" layer, which transparently send those synchronous<br>
messages to the content process (or to the parent process - it can work<br>
both ways).<br>
<br>
What this means is that an add-on using the shim layer can work without<br>
changing any of it's code, at the cost of performance and<br>
responsiveness, because it's doing the Bad Thing: sending synchronous<br>
messages to the content process.<br>
<br>
Add-ons automatically use the shim layer unless they opt out, so if you<br>
have some add-ons in your profile that haven't opted out, they'll be<br>
using them - and if they attempt to touch web content a lot (older<br>
versions of LastPass, for example, did this), this will really bring<br>
browser performance down due to the synchronous messaging.<br>
<br>
Anyhow, I hope that answered your question.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Mike<br>
</font></span><span class="im HOEnZb"><br>
On 25/11/2016 10:32 AM, Girish Sharma wrote:<br>
><br>
> On Fri, Nov 25, 2016 at 8:57 PM, Mike Conley <<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a>>> wrote:<br>
><br>
>     shimmed add-on<br>
><br>
><br>
> What is a shimmed add-on?<br>
><br>
><br>
> --<br>
> Girish Sharma<br>
> B.Tech(H), Civil Engineering,<br>
> Indian Institute of Technology, Kharagpur<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span>Girish Sharma<br>B.Tech(H), </span><span>Civil Engineering</span><span>,</span><div><span>Indian Institute of Technology, Kharagpur</span></div>

</div>
</div>