Closed Bug 1980081 Opened 4 months ago Closed 4 months ago

The document properties set on an XMLDocument disappear after some time. Version 140+

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
143 Branch
Tracking Flags:
Tracking Status
firefox-esr128 --- unaffected
firefox-esr140 --- unaffected
firefox141 blocking verified
firefox142 + verified
firefox143 + verified

People

(Reporter: kluka.kristian, Assigned: alexical)

References

(Regression)

Details

(Keywords: perf-alert, regression)

Attachments

(3 files)

Test case from comment 0
445 bytes, text/html
Details
Bug 1980081 - Backout Eliminate redundant addProperty calls for wrapper preservation r?smaug
48 bytes, text/x-phabricator-request
Details | Review
Bug 1980081 - Backout Eliminate redundant addProperty calls for wrapper preservation r?smaug
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
pascalc
: approval-mozilla-release+
Details | Review

Steps to reproduce:

If we create an object of type XMLDocument with custom property to it, then call evaluate and store its result as global variable, after some time the custom property becomes 'undefined' when accessed via ownerDocument on that global variable. The ownerDocument is accessible, but the custom property no longer exists. Most likely due to garbage collection? This issue appers in version 140+. Works fine in version 139.

Simple test code:

<html>
<script>
    var node;
    function init() {
        var xmlStr = (new window.DOMParser()).parseFromString("<foo><bar>stuff</bar></foo>", "text/xml");
        xmlStr._testParam = true;
        node=xmlStr.evaluate("foo/bar", xmlStr , null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue;
    }

    function checkObj() {
        alert(node.ownerDocument._testParam);
    }
</script>

<body onload="init();">
    <button onClick="checkObj();">Click ME!</button>
</body>
</html>

Actual results:

When you click on "Click ME!" button an alert appears showing "true". After some random amount of time, it displays "undefined".

Expected results:

It should always display "true".

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Confirmed.

mccr8, do you have an idea what's changed here?

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(continuation)

Set release status flags based on info from the regressing bug 1844878

status-firefox141: --- → affected
status-firefox142: --- → affected
status-firefox143: --- → affected
status-firefox-esr128: --- → unaffected
status-firefox-esr140: --- → unaffected

Thanks, Tom, for doing the regression.

[Tracking Requested - why for this release]: Web-visible change in behavior. Maybe it isn't that bad if nobody has reported it, but on the other hand "stuff works but then eventually it doesn't" might be hard to notice.

tracking-firefox142: --- → ?
tracking-firefox143: --- → ?
Flags: needinfo?(continuation)
Flags: needinfo?(dothayer)
Assignee: nobody → dothayer
Status: NEW → ASSIGNED
Flags: needinfo?(dothayer)

The bug is marked as tracked for firefox142 (beta) and tracked for firefox143 (nightly). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(htsai)

I think we shouldn't increase the severity, since we don't have evidence of specific user-facing site breakage, and the specifics of the bug are such that we can't just assume the visibility to users to be severe.

Bug 1980416 looks similar. If there are more of these, perhaps we indeed should raise the severity.

(In reply to Henri Sivonen (:hsivonen) from comment #8)

I think we shouldn't increase the severity, since we don't have evidence of specific user-facing site breakage, and the specifics of the bug are such that we can't just assume the visibility to users to be severe.

This issue is directly related to the bug reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1980416 and significantly impacts Svelte's core reactivity system, potentially affecting thousands of web applications built with this framework.

The bug manifests in our application as unpredictable UI state corruption. A specific reproducible case occurs when users double-click a button that triggers a context menu : the dropdown menu closes properly, but its backdrop element remains active (though transparent). This creates an invisible blocking overlay that prevents user interaction, giving the appearance that the application has frozen.

When this occurs, the application enters an irrecoverable invalid state. Users must refresh the browser page to restore functionality, resulting in the loss of any unsaved work or pending changes.

Given that this affects Svelte's fundamental mechanisms, we anticipate this specific example represents only a fraction of potential symptoms and side effects. The impact could be far more extensive across the Svelte ecosystem.

Thank you

Upgrading to S2 per comment 10.

Severity: S3 → S2
Flags: needinfo?(htsai)

[Tracking Requested - why for this release]:
This seems possibly bad enough that we need to fix this in a dot release.

tracking-firefox141: --- → ?
Attachment #9505023 - Flags: approval-mozilla-release?
Attachment #9505062 - Flags: approval-mozilla-release?
Pushed by dothayer@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/09d3e26ca087 https://hg.mozilla.org/integration/autoland/rev/7670ea9dc076 Backout Eliminate redundant addProperty calls for wrapper preservation r=smaug

Comment on attachment 9505062 [details]
Bug 1980081 - Backout Eliminate redundant addProperty calls for wrapper preservation r?smaug

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Svelte will have the issues mentioned in comment 10, as well as unknown other JS behavioral bugs.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Nothing should have built on top of the bug's changes, and it was a relatively clean backout.
  • String changes made/needed: None
  • Is Android affected?: Yes

https://hg.mozilla.org/mozilla-central/rev/7670ea9dc076

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
status-firefox143: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 143 Branch

The patch landed in nightly and beta is affected.
:alexical, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(dothayer)

Alex, there are two patches with an uplift request to mozilla-release, I am guessing that one of them is for beta, could you change the target branch please? Thanks

Can we get this verified by QA with the test case attached to this bug? Thanks

Flags: qe-verify+

Sorry - not entirely sure what led to me creating duplicate bugs - I must have flubbed something. However, they should be identical, so the one which landed on release should be fine on beta. Let me know if that's alright.

Flags: needinfo?(dothayer)

Pierre-Luc, do you know if there are any automated tests in Svelte that would've triggered this problem and failed?

Flags: needinfo?(plgingras88)
tracking-firefox141: + → blocking
Priority: -- → P1
Attachment #9505062 - Flags: approval-mozilla-beta+
Attachment #9505023 - Flags: approval-mozilla-release?
Depends on: 1981272
QA Whiteboard: [uplift] [qa-ver-needed-c143/b142]

I was able to reproduce the issue with an affected Firefox Nightly 143.0a1 build from 2025-07-31 on Ubuntu 22.04 using the test case attached in Comment 2, after waiting a few second before pressing the "Click ME!" button.
Verified as fixed using Firefox Nightly 143.0a1 (2025-08-05) and Firefox 142.0b8 (treeherder build from Comment 23) on Ubuntu 22.04, macOS 14 and Windows 11. After pressing the "Click ME!" button, the alert displays "true", even after some time has passed.

status-firefox142: fixed → verified
status-firefox143: fixed → verified

(In reply to Jeff Muizelaar [:jrmuizel] from comment #22)

Pierre-Luc, do you know if there are any automated tests in Svelte that would've triggered this problem and failed?

I am not involved in svelte dev, but from what I can understand on their github issues and discussions, no such test exist since it is very low-level, niché and hard to catch depending (the test would sometimes success, sometimes fail).

Flags: needinfo?(plgingras88)
Attachment #9505062 - Flags: approval-mozilla-release? → approval-mozilla-release+

(In reply to Bianca Hidecuti, Desktop Test Engineering [:bhidecuti] from comment #24)

I was able to reproduce the issue with an affected Firefox Nightly 143.0a1 build from 2025-07-31 on Ubuntu 22.04 using the test case attached in Comment 2, after waiting a few second before pressing the "Click ME!" button.
Verified as fixed using Firefox Nightly 143.0a1 (2025-08-05) and Firefox 142.0b8 (treeherder build from Comment 23) on Ubuntu 22.04, macOS 14 and Windows 11. After pressing the "Click ME!" button, the alert displays "true", even after some time has passed.

Also verified as fixed using Firefox 141.0.3-build1 RC on the above mentioned OSes.

Status: RESOLVED → VERIFIED
QA Whiteboard: [uplift] [qa-ver-needed-c143/b142] → [uplift] [qa-ver-done-c143/b142]
status-firefox141: fixed → verified
Flags: qe-verify+
No longer depends on: 1981272
See Also: → 1981272

(In reply to Pulsebot from comment #15)

Pushed by dothayer@mozilla.com:
https://github.com/mozilla-firefox/firefox/commit/09d3e26ca087
https://hg.mozilla.org/integration/autoland/rev/7670ea9dc076
Backout Eliminate redundant addProperty calls for wrapper preservation
r=smaug

Perfherder has detected a browsertime performance change from push 7670ea9dc0760675a9f2eb032c9db030924ee8a3. As author of one of the patches included in that push, we need your help to address this regression.

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy. Our guide to handling regression bugs has information about how you can proceed with this investigation.

If you have any questions or need any help with the investigation, please reach out to a performance sheriff. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Regressions:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
5% speedometer Preact-TodoMVC/Adding100Items/Sync macosx1500-aarch64-shippable fission webrender 0.42 -> 0.45 Before/After
5% speedometer VueJS-TodoMVC/Adding100Items/Sync macosx1500-aarch64-shippable fission webrender 0.63 -> 0.66 Before/After
3% speedometer Preact-TodoMVC/Adding100Items/Sync macosx1500-aarch64-shippable fission webrender 0.43 -> 0.44 Before/After

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a performance sheriff to do that for you.

You can run all of these tests on try with ./mach try perf --alert 46205

The following documentation link provides more information about this command.

Keywords: perf-alert

I'm not particularly worried about it. Those are very minor subbenchmarks and also we can't exactly backout the backout. I'm a little surprised the numbers don't go back down with the landing of bug 1981272, but in either case this is just something to accept.

Duplicate of this bug: 1980416
See Also: 1980416 →
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: