<div dir="ltr"><div>My question would be why would we want to build our own rather than
 use a third-party library? They are probably already well tested and 
maintained - maybe if we had links to some of these libraries that you 
are referring to, we could get a better idea of the complexity level.</div><div><br></div><div class="gmail_extra">Thanks!<br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><b><span style="font-family:trebuchet ms,sans-serif">Jonathan Guillotte-Blouin</span></b><br></div><font size="2"><i>Desktop Firefox Engineering Intern</i></font><br></div></div>
</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 22, 2017 at 10:29 AM, Kris Maglione <span dir="ltr"><<a href="mailto:kmaglione@mozilla.com" target="_blank">kmaglione@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are times when, for the sake of perceived performance, we want to begin preparing for a mouse click as early as possible, so that there's less (or ideally no) perceivable delay after mouseup. We could use simple "mouseover" listeners for this purpose, but the fact that they're triggered any time the mouse travels over an element means they can lead to us doing unnecessary, possibly expensive, work when the use has no intent to interact with an element, and therefore reducing performance overall.<br>
<br>
The particular case I'm dealing with now is our code to begin preloading extension popups on mouseover (with script loading paused until a mousedown event happens). According to telemetry (<a href="https://mzl.la/2sZKBWR" rel="noreferrer" target="_blank">https://mzl.la/2sZKBWR</a>), about 93% of the preloads that we currently trigger are unnecessary.<br>
<br>
So I'd like to update this code (and ideally other similar code, like the network predictor) to try to detect hover intent before triggering the preload. In the wild, that's usually done with some fairly simple JavaScript to begin listening for mouse movements on hover, and watching for deceleration before triggering an action. There are a fair number of libraries for this, but we don't appear to have anything in-tree, so I'm looking for feedback on how we should go about it.<br>
<br>
My preference at this point would be to implement this natively, and dispatch a chrome-only event when the mouse stops (or nearly stops) over an element. I think that would give us the best performance, and be easiest to integrate with the predictor. But the other options are to either import an existing hover intent library, or write our own (which shouldn't be a huge amount of work). But what I definitely don't want to do is implement this in one part of the tree, and then have us wind up doing something different elsewhere.<br>
<br>
Does anyone else have preferences on how we should go about this?<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><b><span style="font-family:trebuchet ms,sans-serif">Jonathan Guillotte-Blouin</span></b><br></div><font size="2"><i>Desktop Firefox Engineering Intern</i></font><br></div></div>
</div>