Page MenuHomePhabricator

[web] Fixed thread name clearing issue in `ThreadSettingGeneralTab`
ClosedPublic

Authored by abosh on May 16 2022, 4:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 13, 1:41 PM
Unknown Object (File)
Nov 23 2024, 11:30 PM
Unknown Object (File)
Nov 23 2024, 10:38 PM
Unknown Object (File)
Nov 23 2024, 8:42 PM
Unknown Object (File)
Nov 9 2024, 3:49 PM
Unknown Object (File)
Nov 9 2024, 3:33 PM
Unknown Object (File)
Nov 9 2024, 3:18 PM
Unknown Object (File)
Nov 9 2024, 6:19 AM

Details

Summary

Fixed issue where the thread name cleared when setting it to anything with the same prefix. The bug was with the firstLine function in onChangeName.

firstLine in onChangeName was introduced in D863 and D862 to make it impossible to set a thread title with newlines, this fix still ensures that.

And for good measure, this also helps resolve the issue in D3980, where the ThreadSettingsGeneralTab button doesn't stay disabled if there are no queued changes.

Related Linear issue with full context here.

Test Plan

Tested on Chrome/Safari and the issue is gone.

Before:

After:

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

abosh edited the test plan for this revision. (Show Details)
abosh added 1 blocking reviewer(s): atul.
Harbormaster returned this revision to the author for changes because remote builds failed.May 16 2022, 5:03 PM
Harbormaster failed remote builds in B9188: Diff 12779!
web/modals/threads/settings/thread-settings-general-tab.react.js
66

The firstLine function returns the empty string when passed undefined as an argument, which made onChangeName set queuedChanges.name to the empty string, not undefined (which would signify that no change should be made). Because queuedChanges.name was set to '', a change was queued, and the thread name would "clear" (be set to the empty string) if the current thread name was equal to the updated thread name.

66

This fix still ensures that there are no newlines in the thread name because it passes target.value into firstLine, but if the new thread name is equal to the current thread name, it sets queuedChanges.name to undefined, unlike before when queuedChanges.name was set to ''.

atul accepted this revision.EditedMay 19 2022, 6:55 AM

Gotcha, so the issue is that when newName is the same as threadInfo.name the ternary "returns" undefined

... and undefined gets passed to the firstLine function
... and firstLine returns the empty string when undefined is passed in
... and so the value of the "Thread name` Input gets set to the empty string
... and results in the Input "clearing" for the user

So the goal was to not queue a change when the input is the same as the existing value, but the outcome was clearing the thread name when it matches the existing one. And the solution was to pull undefined "outside" of the call to firstLine

Good catch

This revision is now accepted and ready to land.May 19 2022, 6:55 AM