1938542 - discussions.apple.com - Unable to post a reply

Status: RESOLVED DUPLICATE of bug 1940594

(Web Compatibility :: Site Reports, defect, P1)

Description

[railioaie]

Environment:
Operating system: Mac OS X 15.2
Firefox version: Firefox 135.0

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate to: https://discussions.apple.com/community/macos/sequoia
2. Try to leave a reply to a post

Expected Behavior:
The user is able to leave a reply

Actual Behavior:
The user is unable to leave a reply

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly
• Does not reproduce in Chrome, Firefox Release

Created from https://github.com/webcompat/web-bugs/issues/145311

Comment 1

[Lou]

FWIW, still broken as of 135.0a1 (2024-12-22) (aarch64). If I remember correctly, the last version that worked was 135.0a1 (2024-12-12) (aarch64)

Comment 2

[Lou]

FWIW, still broken as of 135.0a1 (2024-12-25) (aarch64)

Comment 3

[Lou]

Now running Sequoia 15.3 Beta (24D5034f), nothing's changed.

Comment 4

[Lou]

Just to add, Nightly exhibits the same behavior with any version of macOS.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:ksenia, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Lou]

Just updated to Nightly 136.0a1. Same problem.

Comment 7

[Dennis Schubert [:denschub][OOO, back Jan 12]]

Please stop posting a "still broken" reply every week. We know. :)

Comment 8

[Lou]

Okie doke. :)

Comment 9

[Daniel Holbert [:dholbert]]

Possibly the same issue or possibly different: when trying to perform the STR, I get sent through a first-time Apple Support Community experience where I have to pick a username, and I can't get past that screen in Firefox. It looks like Apple's trying to validate the username that I've entered (as I type each character) and their validation triggers an XHR to https://discussions.apple.com/signup/validate, which gets back a status of 422 Unprocessable Entity.

I'll file a separate bug on that, but it's conceivable that it's the same underlying problem.

Comment 10

[Daniel Holbert [:dholbert]]

I filed bug 1940594 on the thing that I described in comment 9. For now I'm intentionally declining to complete the create-a-username process, so that I preserve the ability to see that UI and test that bug. So for now, that means I'm personally unable to investigate this bug here at all (which requires you to have created a username in order to see/create comments on the actual forum).

I did track down a regression range on bug 1940594, and given the timeline on this bug here (and versions-affected), it seems likely that this is the same underlying issue. In particular, bug 1940594 regressed in Nightly 135, due to bug 1830022's patches landing on Sat Dec 14; and this bug here was filed for Nightly 135 (only affecting Nightly[1]) a few days after that.

So, given the similar manifestation (unable to submit a form) on the same site, that makes me suspect that these are the same underlying bug, both regressions from bug 1830022.

--> moving to diagnosis-team:networking

[1] I'm pretty sure this bug only affected Nightly as of Dec 20th, because:

• Comment 0 mentions that Nightly was affected and release was unaffected at that time
• GitHub user @ikingjr mentioned also mentions (on that same day) that "Firefox 133.0.3 & Firefox Developer work fine for me. Only have the issue with Nightly." So presumably that means the 134 beta version was unaffected at that point (since Developer Edition is based on beta).

Comment 11

[Daniel Holbert [:dholbert]]

railioaie or Lou, would you mind toggling about:config flag network.http.idempotencyKey.enabled to false in Nightly and then see if you can still reproduce this?

That about:config pref seems to the determining factor in the related bug that I filed, so I suspect it's involved here too. Thanks!

Comment 12

[Lou]

That has apparently fixed the problem. Thank you.

Comment 13

[Lou]

Apparently it has caused a new problem. When I copy then paste multi-line text, it apparently ignores the returns at the end of a line.

Comment 14

[Daniel Holbert [:dholbert]]

That's likely a distinct issue, but it's believable that that would have broken recently too. +CC masayuki who's been recently working on the code related to newlines in text editing.

Comment 15

[Lou]

You could be right. I'm lost when it come to this. I can find problems easy enough. I just can't diagnose or fix them. :)

Comment 16

[Lou]

Yes, that's the issue. Thank you.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Lou from comment #12)

That [ toggling about:config flag network.http.idempotencyKey.enabled to false ] has apparently fixed the problem. Thank you.

Great, thanks for confirming that. The good news is that that pref is only enabled in Nightly-branded builds (as an experimental feature) for the forseeable future, so this bug isn't going to affect official Firefox releases anytime soon, I suspect.

Anyway: marking as regression from bug 1830022.

Comment 18

[Lou]

Yes. I mentioned the issue only occurs with Nightly in my original post before it was moved here. I guess something got lost in the translation. :)

Comment 19

[Daniel Holbert [:dholbert]]

Right, I saw that; that's not what I was saying in comment 17 though.

Generally, bugs that affect Nightly 135 (for example) will also affect beta135 and release135 builds (in the near future from when the bug is discovered), as the code that's on Nightly moves into those release versions. My point in comment 17 is that we don't need to worry about that happening in this case (because the behavior in question is behind a specifically Nightly-only flag which defaults to false for beta/release-branded builds).

Comment 20

[Lou]

Understood. I have to worry about it because for years I have been running Nightly without issue as my default browser. I guess I can't do that for now. :)

Comment 21

[Lou]

The multi-line text issue appears to be fixed.

Comment 22

[Daniel Holbert [:dholbert]]

Thanks for confirming. (That part was bug 1940653, whose patch landed yesterday, hence it makes sense for it to be fixed in today's Nightly.)

Comment 23

[Sunil Mayya]

I just confirmed posting a reply using idempotency-key value as a integer rather than quoted string and it works. I propose to close this bug as duplicate of Bug 1940594.

Comment 24

[Dennis Schubert [:denschub][OOO, back Jan 12]]

Closing as duplicate of bug 1940594 as per comment 23. Thanks, Sunil!

Comment 25

[Mathew Hodson]

Moving webcompat link to other bug