Could this have adverse affects on login windows that animate? Fade-in/out for example?

Possibly. That's why I'm little worried. I'll test some sites where I have seen animations before I merge this.

Maybe ignore anything within a FORM element (ie, don't worry about animations if its related to a FORM). This also brings up the discussion of deferring / bundling the checks. You could accumulate a list of activations through mutation observer, overwriting those that repeat, and do the processing on the list once a second or something like that. So if an element is mutating every millisecond you only do the intense processing once per second anyway. We could also build an "ignore list" of elements that are triggered from the mutation observer more than X number of times. Very unlikely those elements would be a login form.

Maybe ignore anything within a FORM element (ie, don't worry about animations if its related to a FORM). This also brings up the discussion of deferring / bundling the checks. You could accumulate a list of activations through mutation observer, overwriting those that repeat, and do the processing on the list once a second or something like that. So if an element is mutating every millisecond you only do the intense processing once per second anyway.

Yes, I've thought something like that. In this case there was just one mutation with minimal changes to the CSS styles, but the class and everything else remains the same. This kind of site is pretty good for testing.

Problems occur if the relevant change is somewhere in the middle of 10 000 different mutations.