If the functions with the below ordering were called, I think 'onload' event is never fired. 1. FrameLoader::checkCompleted() 2. Document::setReadyState(Document::Complete); -- from checkCompleted() 3. HTMLScriptElement::HTMLScriptElement -- from listener of onreadystatechange 4. ScriptRunner::queueScriptForExecution() 5. Document::incrementLoadEventDelayCount() -- from queueScriptForExecution() 6. Document::checkCallImplicitClose() -- from checkCompleted() ---> But it will return immediately because of Document::isDelayingLoadEvent()==true 7. Document::decrementLoadEventDelayCount() is called and timer fired, FrameLoader::checkCompleted() will be called. However, m_isComplete is already set to 'true' then we cannot reach to DOMWindow::dispatchLoadEvent(); I think isDelayingLoadEvent() is necessary to be checked after onreadystatechange to be fired. Firefox, Chrome v30 (not WebKit) on PC are OK.
For reference: https://lists.webkit.org/pipermail/webkit-help/2014-January/003723.html
Created attachment 222255 [details] Test case for this bug to reproduce
Created attachment 222258 [details] Patch I'm not an expert of WebKit. Maybe this is incomplete and will make any side-effects.
When isDelayingLoadEvent() is pending then m_complete should be fale. Changes appears ok to me, I have verified these changes also, It is working fine..
I am not clear on Expected result of test case but all browsers show following output (in Private / Incognito tab or window): interactive complete Recived onload event Browsers tested - Safari 15.6 on macOS 12.5 , Chrome Canary 105 and Firefox Nightly 104 If it is expected result, I think it can be marked as "RESOLVED CONFIGURATION CHANGED" or else test case can be updated etc. Just wanted to share updated results. Thanks!
Yeah, this appears to be fixed now.