https://bugs.documentfoundation.org/show_bug.cgi?id=157287
Matti Tyrväinen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |desktop.org | --- Comment #11 from Matti Tyrväinen <[email protected]> --- > The expand or not expand decision is hard to win, there will be always a > situation where the old behavior was helping some use-case we forgot about. > So restroing the old refmark behavior for now looks like a good idea. And the > next person who wants to change this can now be aware of this catch, to do > better. Thanks. To clarify, the problem isn't whether the behavior helps a use-case, but whether it breaks existing functionality whose implementation depends on the old behavior. I feel this distinction between code changes' effect on UX, and their effect on other code, is worth stressing as their solutions differ. While both can be fixed by restoring the old behavior, implementation bugs can also be fixed by changing the implementation (eg. moving UpdateFieldContent into the object's scope) while workflow-breaking behavior changes would require changing the workflow. The new behavior should actually help in this use-case, as expanding the refmark in the cell by typing also stops it from updating, but until someone reworks the implementation behind the functionality used here, I agree that reverting it is appropriate. > Matti, please submit the patch on gerrit Done: https://gerrit.libreoffice.org/c/core/+/158059 Apologies for spamming Jenkins, couldn't test locally due to bump in GCC's required version. -- You are receiving this mail because: You are the assignee for the bug.
