1937425 - `<textarea>`s render cached content, across refreshes and browser invocations.

Status: UNCONFIRMED

(Core :: Session Restore, defect)

Description

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

How To Reproduce

1. I saved (posted) a comment on GitHub (or GitLab).

2. I modified that comment.

3. I saved (posted) that (modified) comment.

4. I entered the edit mode again.

Actual Result

Instead of displaying the updated comment content, the previous content is displayed. Refreshing the page once usually remediates this, and refreshing it 2 to 3 times always does.

I presume that this is due to caching, considering that input form content is usually cached, except upon manual refresh.

I would have considered this to be a fault with either GitHub or GitLab, had it not occurred on both. It occurs on GitHub incredibly frequently, in comparison to GitLab.

Expected Result

The new content should be displayed.

My Environment

The latest version reproduced on is 145.0.1.

Comment 1

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

#c0

I have not verified whether this is exhibited on Firefox on Windows 11, nor whether it's exhibited on Chrome, because I rarely utilize either platform (although both are available to me if necessary) so the sporadic nature of the bug makes it difficult to reproduce on those platforms without extensive use of them.

Comment 2

[Henri Sivonen (:hsivonen)]

Works for me on GitHub. Reporter, are the steps to reproduce from comment 0 sufficient for you to reproduce this on GitHub?

Comment 3

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Reporter, are the steps to reproduce from comment 0 sufficient for you to reproduce this on GitHub?

[e-mail], yes. Additionally:

1. The reproduction steps are identical on GitHub and GitLab.
2. This occurs approximately 90% more frequently on GitHub in my usage, although my usage is skewed significantly toward GitHub.

I'll attempt to capture a screencast when this next occurs.

Comment 4

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

#a574469_691781

It's been strangely reliable recently. I'll reopen when I have captured a screencast as proof.

Comment 5

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Location And Environment

#c4

I have had this recur at gitlab.com/-/snippets/4823517/edit at least 2 times today, on a new installation of firefox-136.0-2.fc41.x86_64 on a new OS installation, but with my previous profile (albeit with [e-mail] disabled). I verified by refreshing the page.

Comment 6

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Attachment: A Screencast That Demonstrates Reproduction At GitLab Via The Synchronised Profile On Desktop

Demonstration

#c5

I've finally recorded reproduction without that problematic extension active.

Comment 7

[Sean Feng [:sefeng211]]

Just to note that the issue in the screencast was blog.burnsmcd.com in the rendered markdown, but not in the editor.

Is it reproducible with a clean profile?

Comment 8

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Is it reproducible with a clean profile?

I can't easily tell, because it's so inconsistent. It certainly occurs infinitely more on GitLab (especially Snippets) than on GitHub, but I don't have a definitive way to evaluate this. Is there something I can check in the DevTools when I encounter it that demonstrates that the browser is loading cached content?

I suppose it could be feasible for me to create two test Snippets. One, I edit on a new profile, and the other on the current profile. I keep editing until it either appears or I've tried for long enough that it doesn't.

Comment 9

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Attachment: A Screencast That Demonstrates Reproduction At GitLab Via A New Profile On Desktop

I suppose it could be feasible for me to create two test Snippets. One, I edit on a new profile, and the other on the current profile. I keep editing until it either appears or I've tried for long enough that it doesn't.

Since it's already reproduced in my default profile, I created a snippet and added its content via my default profile, then exited it, and modified it thereafter solely in the new profile. It immediately reproduced on the first edit, didn't for some time, but eventually did again. I managed to screencast the last reproduction.

Comment 10

[Andreas Farre [:farre]]

Would you be comfortable sharing a https://profiler.firefox.com/ profile captured while you're reproducing this? It'd allow us to get some hints about where the problem occurs.

Comment 11

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Diagnosis

#c10

Apologies for the wait. I've managed to capture a surprisingly short profile at share.firefox.dev/42AoWVj, in which I confirmed that the issue reproduced.

Comment 12

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Location And Remediation

Had this reproduce at https://github.com/rogalmic/vscode-bash-debug/issues/197#issue-3024235077 on org.mozilla.fenix, which I previously considered unaffected. Specifically, I loaded the page, modified the comment, and on refresh after submission (refresh shouldn't occur), was displayed the cached page without my modification. After manual refresh, the modification appeared.

Environment

2025-05-13T00:30:19.561342428:

140.0a1 (Build #2016090567), hg-6994db615d7f+
GV: 140.0a1-20250512213630
AS: 140.20250509050400
OS: Android 14

Comment 13

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Attachment: A Screencast That Demonstrates Reproduction At Mozilla's Bugzilla Instance Via The Synchronised Profile On `Mozilla.Firefox_139.0.0.0_x64__n80bbvh6b1yt2`

Location And Environment

I have managed to reproduce this with id=1969259#c3 on my FFA-synchronised profile, via Mozilla.Firefox_139.0.0.0_x64__n80bbvh6b1yt2 from apps.microsoft.com/detail/9nzvdkpmr9rd:

Publisher         : CN=082E9164-EE6C-4EC8-B62C-441FAE7BEFA1
ResourceId        :
InstallLocation   : C:\Program Files\WindowsApps\Mozilla.Firefox_139.0.0.0_x64__n80bbvh6b1yt2
IsFramework       : False
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Remediation

This on a new browser invocation: I had saved the content on the previous invocation, then exited. A location.reload() remediated it.

Comment 14

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

Attachment: A Screencast That Demonstrates Reproduction At GitLab Via The Synchronised Profile On org.mozilla.fenix 141.0a1 (2016097671)

Where Reproduced

gitlab.com/-/snippets/4809739.

Via What (The Environment)

141.0a1 (Build #2016097671), null

GV: 141.0a1-20250618211250
AS: 141.20250617050355
OS: Android 14

2025-06-18T21:12:50

Comment 15

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

I experienced this with rendered content, after gitlab.com/gitlab-org/gitlab/-/work_items/596800#note_3253698033, with firefox-nightly-151.0a1-20260415040720. IDK whether that's relevant, or server-side.