Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-117667

REG: TextEdit height gets stuck due to binding loops (forever) or anchor changes (temporarily until further resize event)

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P1: Critical
    • None
    • 6.5, dev
    • None
    • d84c13041 (dev), 3bff95324 (6.7), 4cf08f075 (6.6), 6a727f500 (tqtc/lts-6.5)

    Description

      TextEdit fails to update its height under certain conditions on Qt 6. This is a regression from Qt 5.15. Screenshots show 3 windows of the same QML scene run with Qt 5.15.10+kde+r158-1, Qt 6.5.2-1, and custom-built Qt dev (from about a week or two ago).

      First of all, using anchors + height results in a binding loop. This binding loop is demonstrated in the top-most red block on my screenshots. Note that it still manages to end up with correct size on Qt 5, despite the complains; but fails to do so on Qt 6 after exactly two resizes (expand to single-line and shrink back to multi-line).

      Then, an alternative approach using Item::state somehow manages to avoid binding loops between AnchorChanges and PropertyChanges on height. And here I hit a bug in TextEdit resizing/layout: with wrapMode: Text.WordWrap, verticalAlignment: Text.AlignVCenter and a very specific combination of state changes, while shrinking the TextEdit into becoming multi-line, on the very same frame when it becomes multi-line — its height resets correctly but the actual text gets stuck vertically centered; and only on the next resize event (when shrinking further) the text get repositioned correctly on the top.

      This works on the first redraw:

      states: [
          State {
              name: "multi-line"
              when: target3.lineCount > 1
              AnchorChanges {
                  target: target3
                  anchors.bottom: undefined
              }
              PropertyChanges {
                  target: target3
                  height: target3.implicitHeight
              }
          },
          State {
              name: "single-line"
              when: true
              AnchorChanges {
                  target: target3
                  anchors.bottom: target3.parent.bottom
              }
          }
      ]
      

      But if you swap height: target3.implicitHeight with height: undefined or remove it altogether, then it gets stuck. If you skip anchors.bottom: undefined, then it break in another creative way: the whole TextEdit becomes thin as it is were single-line while displaying multi-line text layout, and no amount of resizing helps until it is expanded enough to become truly single-line again.

      Note: the middle orange block can be "fixed" for Qt 5 by adding the following change set for "single-line" state. It seems like it should conflict with bottom anchor and should actually cause a binding loop, but it… magically doesn't.

      PropertyChanges {
          target: target2
          height: target2.implicitHeight
      }
      

      I have a theory why height: undefined does not work. "Unset" is the default state for width/height properties, so assigning "undefined" to reset it simply short-circuits and doesn't really do any work, even when doing would help it "unstuck".

      I have no idea why explicit anchors.bottom: undefined is required though. "Unset" is also the default state for anchors, so leaving a State which had AnchorChanges in it should restore back the "unset" value, I guess?

      And neither of that explain why text layout gets stuck vertically centered, and only fixes up itself on a next polish.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              oulu_hillbilly Sami Varanka
              ratijas ivan tkachenko
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes