Open Bug 2020500 Opened 4 months ago Updated 4 months ago

BMO often reports that a user has edited the User Story field, when they did not actively do so

Categories

(bugzilla.mozilla.org :: Bug Creation/Editing, defect)

Production
defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

Details

From time to time, I see cases where I or someone else makes a trivial change to a bug, and the bugmail (and bugzlla history / comment-stream) reports that they edited the User Story field, even though they didn't actually touch that field.

The change always looks like the entire contents of the user story have been deleted (as indicated with -) and then added back (as indicated with +).

I suspect this has something to do with newline encoding or something else whitespace-related, where the user's browser fixes up the newlines in the user-story field in some way, and then that gets lumped in as an update, when they make an edit to any other field.

Ideally it'd be great to avoid having this happen, because it can be confusing/off-putting for new users, and it's non-trivial to verify whether you did in fact make some sort of subtle change to the field's contents by accident (as Bugzilla seems to be blaming you for doing).

The recent case where I saw this was here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1939472#a36907075_278074

Bugzilla shows "User Story: (updated)" in the comment-stream there (but I did not in fact touch the user-story field).

And the bug history (https://bugzilla.mozilla.org/show_activity.cgi?id=1939472 ) superficially shows that I removed nearly the entire contents of that field and replaced it with the exact same contents:

@@ -1,7 +1,7 @@
-platform:windows,mac,linux,android
-impact:minor-visual
-configuration:general
-affects:all
-branch:release
-diagnosis-team:layout
+platform:windows,mac,linux,android
+impact:minor-visual
+configuration:general
+affects:all
+branch:release
+diagnosis-team:layout
user-impact-score:30

Notably, it shows the final line (user-impact-score:30) as being untouched, but all the previous lines as having been removed and added back. So that's a strong clue that this might be related to something related to newlines or some other sort of non-visible end-of-line control character (something that's "unstable" in some way, and present on all but the last line).

See Also: → 1988539

I'm using Firefox Nightly on Linux (Ubuntu 26.10), FWIW.

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