Open Bug 1978709 Opened 21 days ago Updated 10 hours ago

`window.onload` is being unexpectedly triggered in Firefox 140+ after executing synchronous JavaScript code that includes a `$(document).ready(...)` block. This only occurs in Firefox and only from version 140 onward.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
Firefox 140
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: jimycoelho, Assigned: edgar, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

teste-ff-140-B.html
3.98 KB, text/html
Details
Screenshot of final result of mozregression
212.66 KB, image/png
Details
Full log of mozregression.
141.97 KB, text/x-log
Details
Bug 1978709 – Fix issue where load event might fire unexpectedly when loading a JavaScript URI; r?smaug
48 bytes, text/x-phabricator-request
Details | Review
Attached file teste-ff-140-B.html —

Steps to reproduce:

Steps to Reproduce

  1. Create a page that:

    • Uses window.onload to initialize a script;
    • Uses jQuery 3.7.1;
    • Contains a function that:
      • Executes a synchronous XMLHttpRequest POST;
      • Then calls $(document).ready(...) inside the callback logic.

  2. Trigger this function via a user interaction (e.g., clicking a list item).

  3. Observe the console logs.

Affected Browsers

Browser Version Result
Firefox 128.5.2 ESR ✅ OK
Firefox 139.0.4 ✅ OK
Firefox 140.0 ❌ Bug occurs
Firefox 140.0.4 ❌ Bug occurs
Firefox 141.0 ❌ Bug occurs
Chrome 138.0 ✅ OK
Edge 138.0 ✅ OK
Opera 120.0 ✅ OK

Additional Notes

  • If $(document).ready(...) is removed, the bug does not occur.
  • If a breakpoint is placed immediately after the synchronous POST, the bug also does not occur.
  • This suggests a possible timing or event loop regression introduced in Firefox 140+.
  • The issue does not appear when only using jQuery or only using sync requests — both together seem to trigger it.

Attachments

I’m attaching a reduced HTML test file (teste-ff-140-B.html) that mimics the structure and behavior of the legacy application where the issue was first discovered. While the issue is not always reproducible in this file, the pattern is consistent with what causes the issue in our production application.

Environment

  • jQuery version: 3.7.1
  • Firefox version: 140.0+ (confirmed on 140.0, 140.0.4, and 141.0)
  • Application type: Legacy JSP application (complex, proprietary, restricted access)

Actual results:

Actual Result

  • window.onload is triggered again after calling $(document).ready(...), even though the page is not reloaded or navigated.

Expected results:

Expected Result

  • window.onload should only be triggered once, after the full page is loaded.

Sample Output (expected vs actual):

✅ Expected:

2025-07-22T13:32:26.000Z - window.onload
XHR POST (click on item 1)
2025-07-22T13:32:30.000Z - document.ready
XHR POST (click on item 2)
2025-07-22T13:32:32.000Z - document.ready

❌ Actual:

2025-07-22T13:32:26.000Z - window.onload
XHR POST (click on item 1)
2025-07-22T13:32:30.000Z - document.ready
2025-07-22T13:32:30.200Z - window.onload <<<< Unexpected
XHR POST (click on item 2)
2025-07-22T13:32:32.000Z - document.ready
2025-07-22T13:32:32.150Z - window.onload <<<< Unexpected

This appears to be a regression from Firefox 139 to 140. Possibly related to recent changes in event loop or DOM event scheduling. Flagging as potential regression.

I can't repro this on nightly at least fwiw...

QA Whiteboard: [qa-triage-done-c143/b142][qa-investig-needed-c143/b142]

I tested with Firefox 142.0b1 (nightly) in production application and error persists.

Correcting my last comment.
I tested with Firefox version 142.0b1 (beta) and version 143.0a1 (2025-07-23) (nightly) in the production application and the error persists.

Can you link to the production application? Can you reproduce with the page you attached (i.e., from this link)?

Flags: needinfo?(jimycoelho)

If you can reproduce it consistently on your application, could you try to run mozregression and post the result here? That'd help to see what caused this.

Unfortunately, the private production environment is only accessible via an internal VPN, and a username and password are required to access the functionality where the error is occurring. I'll reproduce the error with mozregression and post the results here.

Flags: needinfo?(jimycoelho)

I ran mozregression, final log message:

2025-07-24T12:38:08.196000: DEBUG : Found commit message:
Bug 1934092 - Fire load event for javascript URIs with non-string evaluation results; r=smaug

https://github.com/whatwg/html/issues/1895

Differential Revision: https://phabricator.services.mozilla.com/D244416

I will attach the log and screenshot.

Thanks for the mozregression, that bug looks like it could be responsible. I'll add Edgar into the loop, he's on PTO until next week though.

Flags: needinfo?(echen)
Regressed by: 1934092

🆕 Additional Scenario Where the Bug Occurs

I've encountered the same unexpected behavior in another functionality of the application.

💡 Scenario:

An <a> tag is placed inside a <html:form> (from JSP/Struts). When the link is clicked, it calls a JavaScript method named report, which:

  1. Executes a synchronous XMLHttpRequest;
  2. Immediately submits the form via form.submit(), triggering a Struts action that returns a PDF, which is opened in another browser tab.

❌ Unexpected Behavior:

  • The PDF opens correctly in a new tab (as expected).
  • However, the main page triggers window.onload again, even though no reload occurred.
  • This only happens in Firefox version 140 and above.
  • The result from mozregression points to the same changeset as the previously described case.

🔁 Reproduction:

Unfortunately, the issue could not be reproduced in a simplified standalone test case. It seems to depend on the full integration of JSP + Struts + synchronous JS + submit behavior.

🛠️ Simplified Code Snippet

Here is a simplified version of the structure where the issue occurs, along with a workaround currently used to avoid side effects from the unwanted onload trigger.

<html:form action="/myStrutsAction" method="post" styleId="myForm">
  <a href="javascript:void(report(document.forms[0], 'rep1'))">Download PDF</a>
</html:form>

<script>
  function loadPage() {
    console.log('window.onload');
    // This function should only be called once, when the full page is loaded.
    // If triggered unexpectedly, it may break application logic.
  }

  function report(form, action) {
    // Performs a synchronous HTTP POST via XMLHttpRequest (simulated)
    // Submits the form, triggering a Struts action that returns a PDF in a new tab
    form.submit();
  }

  let loaded = false;

  window.onload = function() {
    // 🔧 Workaround for Firefox 140+ bug
    if (loaded) {
      console.warn('window.onload triggered again – ignoring');
      return;
    }
    loaded = true;
    loadPage();
  };
</script>

This confirms that the issue is not limited to jQuery + document.ready, but also affects traditional form + submit flows in combination with synchronous requests in Firefox 140+.

If Firefox internal logs are needed, I’d be glad to provide them — I may just need guidance on how to collect them.

Assignee: nobody → echen
Severity: -- → S2
Flags: needinfo?(echen)
Keywords: regressionwindow-wanted

Thanks for reporting this! Is it possible to capture a profile with reproducing the issue in the production environment and share the link here? Perhaps we could find some clue from the information captured in the profile.

Flags: needinfo?(jimycoelho)

I exported two profiles using Firefox Profiler with version Nightly 143.0a1 (2025-07-31):

For both cases, I started recording before entering the affected functionality, and stopped recording immediately after the unexpected window.onload event was triggered.

Let me know if you'd prefer I capture a more targeted recording (for example, starting only right before the click that causes the issue), or if there's a specific profiler configuration (e.g., category filters or threads) that would be more useful for debugging.

Flags: needinfo?(jimycoelho)

Ademir, one more thing needs your help, could you also help to capture log for DocLoader module?

  1. load about:logging
  2. Set log module to timestamp,sync,DocLoader:5
  3. Enable Enable stack traces for log messages
  4. Start logging by pressing Start logging button
  5. (reproduce the issue)
  6. Stop logging by pressing Stop logging button
  7. Share the profile link

Thank you!

Flags: needinfo?(jimycoelho)

As requested, I captured new logs using about:logging, running on Firefox Nightly 143.0a1 (2025-08-04).

There are two distinct scenarios where the issue occurs:

  • Scenario 1: A list of items where clicking an item triggers a synchronous request and uses jQuery $(document).ready(...).
  • Scenario 2: A link that performs a synchronous request and submits a <form> triggering a Struts action that returns a PDF in a new tab.

In both scenarios, I captured two versions:

  • One covering the full user flow from the beginning of the functionality;
  • Another focusing only on the action that triggers the unexpected window.onload event.

Here are the links:

Scenario 1:

Scenario 2:

In all captures, I stopped the recording immediately after the unexpected window.onload event was triggered. Let me know if you'd like a different logging configuration or a deeper capture focusing on a specific module.

Flags: needinfo?(jimycoelho)

Thanks for the log, it helps a lot. It looks both cases are the same cause, clicking a link with javascipt URL also triggers image loads, and somehow the image loads complete first. And DocLoader incorrect fire a load event for that due to the mIsLoadingJavascriptURI flag.

I understand that the lack of a clear, standalone scenario makes it harder to resolve the issue. That’s why I’ve made several attempts to reproduce the problem in a simplified example — unfortunately, the issue only occurs under specific conditions in the real application I support.

I ran mozregression, and from what I understand, it successfully identified the commit where the behavior changed.

Given the details from that commit and the logs already provided, would it be possible to determine what needs to be adjusted to fix this regression?

If necessary, I’m available to test a patch to help confirm the fix.

Hi Ademir, here are the test builds, could you help to test if it fixes the isssue on your side?

(If you need builds for other platform, please let me know)

Edited: There are new test builds in comment #21.

Flags: needinfo?(jimycoelho)

The issue occurs when a JavaScript URI is being loaded while image loads are also
triggered at the same time. If images finish loading before the Javascript URI
completes execution, e.g. requested images are avaiable in image cache or a
synchronous XHR is spining the event loop, the load event might be fired unexpectedly.
This is primarily because the Javascript URI loading is tracked as a state in DocLoader,
when image load complete, DocLoader erroneously determines to fire load event
due to document is in Javascript URI loading state.

The checks performed in OnStopRequest for nsIScriptChannel already covers everyhting
needed for load event dispatching when loading a Javascript URI, using a sepearated
state to track in DocLoader isn't necessary.

This is new test build:

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: