[BUGFIX beta] reimplement $.ready()

[rreckonerr]

TODOs

• refactor waitForDOMReady away from jQuery
• figure out if !this.$ === !hasDOM
• fix failing tests in packages/@ember/application/tests/readiness_test.js
  • find a way to restore mocked readyState or a better way to mock it
  • improve coverage for advanceReadiness/deferReadiness cases

NOTES

• jquery .ready() implementation:

  function completed() {
    document.removeEventListener( "DOMContentLoaded", completed );
    window.removeEventListener( "load", completed );
    jQuery.ready();
  }
  
  
  // Catch cases where $(document).ready() is called
  // after the browser event has already occurred.
  if ( document.readyState !== "loading" ) {
  
  
    // Handle it asynchronously to allow scripts the opportunity to delay ready
    window.setTimeout( jQuery.ready );
  
  
  } else {
  
  
    // Use the handy event callback
    document.addEventListener( "DOMContentLoaded", completed );
  
  
    // A fallback to window.onload, that will always work
    window.addEventListener( "load", completed );
  }

[rreckonerr]

Fixes #19134

[chancancode]

Thanks for looking into this. I talked to @rwjblue about this and he wanted to do some benchmarks to confirm this restoring the old behavior won't cause any regressions. I think he was planning to benchmark it against my workaround, but if this works then they can probably test this directly.

I also realized a problem with the approach here. I think we are not supposed to rely on document existing due to fastboot, but that presents a chicken-and-egg problem because I'm not sure how we would get the non-global document object to use here, since it's usually passed/injected via the boot() method as one of the options.

Maybe it's not a big deal since fastboot disables autoboot and wouldn't hit this code path anyway. @rwjblue/@krisselden do you have any thoughts? Is this just fine or should we at least guard accessing the document global and the event handling methods? (See comment thread below.)

[rreckonerr]

@chancancode
By the way, is $.ready() the last thing that stops us from passing foreign document object for iframe support?
It's mentioned in supported scenarios section in documentation:

For example, booting the instance in the full browser environment
while specifying a foreign document object (e.g. { isBrowser: true, document: iframe.contentDocument }) does not work correctly today,
largely due to Ember's jQuery dependency.