discord not working after refresh
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox151 | --- | unaffected |
| firefox152 | --- | disabled |
| firefox153 | --- | fixed |
| firefox154 | --- | fixed |
People
(Reporter: mix5003, Assigned: arai)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0
Steps to reproduce:
- go to some channel in discord
- refresh
Actual results:
it loading forever
Expected results:
it should load discord correctly.
Video for my problem: https://youtu.be/ZmmMqSRYZRE
in video i show 2 think that can solve issue.
- use dev tool then tick "disable cache" then refresh
- set
dom.script_loader.experimental.navigation_cacheto false (for confirm mozregression bug)
and another way but i can not show in video is close tab then re-open again
Mozregression
2026-06-01T16:11:06.309000: DEBUG : Found commit message:
Bug 2027803 - Enable stencil navigation cache on nightly. r=nbp
Differential Revision: https://phabricator.services.mozilla.com/D291097
2026-06-01T16:11:06.312000: DEBUG : Did not find a branch, checking all integration branches
2026-06-01T16:11:06.313000: INFO : The bisection is done.
2026-06-01T16:11:06.459000: INFO : Stopped
Nightly profiler: https://share.firefox.dev/4o0J0cE
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Gecko Profiler' component, but is not confident enough to move the bug to that component.
Comment 2•2 months ago
|
||
Nicolas could you take a look?
Updated•2 months ago
|
Updated•2 months ago
|
Comment 3•2 months ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 4•2 months ago
|
||
Applying the "after" patch from bug 1999884 comment 1 reliably fixes this issue on my workstation, but insight.min.js doesn't seem to be involved like it is in bug 2042605.
I've experimented with only delaying one script at a time, but haven't found the script that fixes the issue when it is delayed.
Unassigning myself because I'm going on PTO. :arai, can you take a look?
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 5•2 months ago
|
||
The issue seems to be caused by the discord's loader functionality, which reuses script elements across multiple loads, and also uses onload event handler.
Discord loads 600+ script files, and each of them adds an element to this.webpackChunkdiscord_app array.
In the working case, it has 665 elements, but in the broken case, it has only 604 elements,
which means the load stops at some point.
https://discord.com/assets/web.c15e47a2f6e8fddd.js
A.l = function (e, t, n, i) {
if (u[e]) return void u[e].push(t);
if (void 0 !== n) for (
var r,
s,
a = document.getElementsByTagName('script'),
o = 0;
o < a.length;
o++
) {
var l = a[o];
if (
l.getAttribute('src') == e ||
l.getAttribute('data-rspack') == 'discord_app:' + n
) {
r = l;
break
}
}
r ||
(
s = !0,
(r = document.createElement('script')).timeout = 120,
A.nc &&
r.setAttribute('nonce', A.nc),
r.setAttribute('data-rspack', 'discord_app:' + n),
r.src = e
),
u[e] = [
t
];
var c = function (t, n) {
r.onerror = r.onload = null,
clearTimeout(d);
var i = u[e];
if (
delete u[e],
r.parentNode &&
r.parentNode.removeChild(r),
i &&
i.forEach(function (e) {
return e(n)
}),
t
) return t(n)
},
d = setTimeout(c.bind(null, void 0, {
type: 'timeout',
target: r
}), 120000);
r.onerror = c.bind(null, r.onerror),
r.onload = c.bind(null, r.onload),
s &&
document.head.appendChild(r)
}
For me, applying a delay only to https://discord.com/assets/03f84c299966cd36.js solves the issue,
but this is a localization file specific to Japanese, so it will be different for each user.
Anyway, bug 2042605 and also this bug proves that synchronously processing the script can cause issues,
and this situation happens only for in-memory cache, which doesn't require any IPC or network communication.
Thus, it should be reasonable to introduce one tick delay before processing the script, so that nothing is processed synchronously
after inserting the script element.
| Assignee | ||
Comment 6•2 months ago
|
||
Updated•2 months ago
|
Updated•2 months ago
|
Comment 8•2 months ago
|
||
| bugherder | ||
| Assignee | ||
Comment 9•2 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D306434
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 10•2 months ago
|
||
| uplift | ||
Updated•1 month ago
|
Description
•