← Back to team overview

ubuntu-sdk-bugs team mailing list archive

[Bug 1588238] [NEW] Flickable's widthRatio and heightRatio are wrong when the content is smaller than the view and has topMargin/leftMargin

 

Public bug reported:

UPSTREAM BUG: https://bugreports.qt.io/browse/QTBUG-53726

Description (copied from the upstream bug I created)

According to Flickable's documentation, widthRatio and heightRatio define
"the percentage of the full view currently visible, scaled to 0.0 - 1.0".
At the moment, defining leftMargin so that
leftMargin+contentWidth < flickable.width
causes widthRatio to be wrongly evaluated to something != 1, whereas it should be 1, because Flickable's defaults at -leftMargin
(see https://github.com/qtproject/qtdeclarative/blob/5.6/src/quick/items/qquickflickable.cpp#L1592 ).
and when contentX is -leftMargin, the whole content fits inside the view.
As a consequence of that, in the current implementation you can also scroll the item from the testcase left and right, which shouldn't be possible (because item+margin are still smaller than the view).

============================

Additional Ubuntu-specific info:
This is currently blocking the correct implementation of the new scrollbars inside TextFields (ping kalikiana or me (faenil) on IRC for more info)

========TESTCASE============

import QtQuick 2.0

Flickable {
    id: flickable
    width: 200
    height: 200
    contentWidth: item.width
    contentHeight: item.height
    topMargin: 20
    leftMargin: 40
    Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
    Connections {
        target: flickable.visibleArea
        onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
        onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
    }
    Rectangle {
        id: item
        width: 100
        height: 100
        color: "black"
    }
}

===========================

How to reproduce:
1) qmlscene testcase.qml
2) watch the console output

Actual result: widthRatio is != 1
Expected result: widthRatio == 1

===========================

Fix: I worked on a fix which is being reviewed by upstream --->
https://codereview.qt-project.org/#/c/161043/

** Affects: qtdeclarative-opensource-src (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  UPSTREAM BUG: https://bugreports.qt.io/browse/QTBUG-53726
  
  Description (copied from the upstream bug I created)
  
  According to Flickable's documentation, widthRatio and heightRatio define
  "the percentage of the full view currently visible, scaled to 0.0 - 1.0".
- At the moment, defining leftMargin so that 
+ At the moment, defining leftMargin so that
  leftMargin+contentWidth < flickable.width
  causes widthRatio to be wrongly evaluated to something != 1, whereas it should be 1, because Flickable's defaults at -leftMargin
  (see https://github.com/qtproject/qtdeclarative/blob/5.6/src/quick/items/qquickflickable.cpp#L1592 ).
  and when contentX is -leftMargin, the whole content fits inside the view.
  As a consequence of that, in the current implementation you can also scroll the item from the testcase left and right, which shouldn't be possible (because item+margin are still smaller than the view).
  
- 
  ========TESTCASE============
  
  import QtQuick 2.0
  
  Flickable {
-     id: flickable
-     width: 200
-     height: 200
-     contentWidth: item.width
-     contentHeight: item.height
-     topMargin: 20
-     leftMargin: 40
-     Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
-     Connections {
-         target: flickable.visibleArea
-         onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
-         onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
-     }
-     Rectangle {
-         id: item
-         width: 100
-         height: 100
-         color: "black"
-     }
+     id: flickable
+     width: 200
+     height: 200
+     contentWidth: item.width
+     contentHeight: item.height
+     topMargin: 20
+     leftMargin: 40
+     Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
+     Connections {
+         target: flickable.visibleArea
+         onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
+         onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
+     }
+     Rectangle {
+         id: item
+         width: 100
+         height: 100
+         color: "black"
+     }
  }
  
  ===========================
  
  How to reproduce:
  1) qmlscene testcase.qml
  2) watch the console output
  
  Actual result: widthRatio is != 1
  Expected result: widthRatio == 1
+ 
+ ===========================
+ 
+ Fix: I worked on a fix which is being reviewed by upstream --->
+ https://codereview.qt-project.org/#/c/161043/

** Description changed:

  UPSTREAM BUG: https://bugreports.qt.io/browse/QTBUG-53726
  
  Description (copied from the upstream bug I created)
  
  According to Flickable's documentation, widthRatio and heightRatio define
  "the percentage of the full view currently visible, scaled to 0.0 - 1.0".
  At the moment, defining leftMargin so that
  leftMargin+contentWidth < flickable.width
  causes widthRatio to be wrongly evaluated to something != 1, whereas it should be 1, because Flickable's defaults at -leftMargin
  (see https://github.com/qtproject/qtdeclarative/blob/5.6/src/quick/items/qquickflickable.cpp#L1592 ).
  and when contentX is -leftMargin, the whole content fits inside the view.
  As a consequence of that, in the current implementation you can also scroll the item from the testcase left and right, which shouldn't be possible (because item+margin are still smaller than the view).
+ 
+ ============================
+ 
+ Additional Ubuntu-specific info:
+ This is currently blocking the correct implementation of the new scrollbars inside TextFields (ping kalikiana or faenil on IRC for more info)
  
  ========TESTCASE============
  
  import QtQuick 2.0
  
  Flickable {
      id: flickable
      width: 200
      height: 200
      contentWidth: item.width
      contentHeight: item.height
      topMargin: 20
      leftMargin: 40
      Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
      Connections {
          target: flickable.visibleArea
          onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
          onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
      }
      Rectangle {
          id: item
          width: 100
          height: 100
          color: "black"
      }
  }
  
  ===========================
  
  How to reproduce:
  1) qmlscene testcase.qml
  2) watch the console output
  
  Actual result: widthRatio is != 1
  Expected result: widthRatio == 1
  
  ===========================
  
  Fix: I worked on a fix which is being reviewed by upstream --->
  https://codereview.qt-project.org/#/c/161043/

** Description changed:

  UPSTREAM BUG: https://bugreports.qt.io/browse/QTBUG-53726
  
  Description (copied from the upstream bug I created)
  
  According to Flickable's documentation, widthRatio and heightRatio define
  "the percentage of the full view currently visible, scaled to 0.0 - 1.0".
  At the moment, defining leftMargin so that
  leftMargin+contentWidth < flickable.width
  causes widthRatio to be wrongly evaluated to something != 1, whereas it should be 1, because Flickable's defaults at -leftMargin
  (see https://github.com/qtproject/qtdeclarative/blob/5.6/src/quick/items/qquickflickable.cpp#L1592 ).
  and when contentX is -leftMargin, the whole content fits inside the view.
  As a consequence of that, in the current implementation you can also scroll the item from the testcase left and right, which shouldn't be possible (because item+margin are still smaller than the view).
  
  ============================
  
  Additional Ubuntu-specific info:
- This is currently blocking the correct implementation of the new scrollbars inside TextFields (ping kalikiana or faenil on IRC for more info)
+ This is currently blocking the correct implementation of the new scrollbars inside TextFields (ping kalikiana or me (faenil) on IRC for more info)
  
  ========TESTCASE============
  
  import QtQuick 2.0
  
  Flickable {
      id: flickable
      width: 200
      height: 200
      contentWidth: item.width
      contentHeight: item.height
      topMargin: 20
      leftMargin: 40
      Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
      Connections {
          target: flickable.visibleArea
          onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
          onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
      }
      Rectangle {
          id: item
          width: 100
          height: 100
          color: "black"
      }
  }
  
  ===========================
  
  How to reproduce:
  1) qmlscene testcase.qml
  2) watch the console output
  
  Actual result: widthRatio is != 1
  Expected result: widthRatio == 1
  
  ===========================
  
  Fix: I worked on a fix which is being reviewed by upstream --->
  https://codereview.qt-project.org/#/c/161043/

-- 
You received this bug notification because you are a member of Ubuntu
SDK bug tracking, which is subscribed to qtdeclarative-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1588238

Title:
  Flickable's widthRatio and heightRatio are wrong when the content is
  smaller than the view and has topMargin/leftMargin

Status in qtdeclarative-opensource-src package in Ubuntu:
  New

Bug description:
  UPSTREAM BUG: https://bugreports.qt.io/browse/QTBUG-53726

  Description (copied from the upstream bug I created)

  According to Flickable's documentation, widthRatio and heightRatio define
  "the percentage of the full view currently visible, scaled to 0.0 - 1.0".
  At the moment, defining leftMargin so that
  leftMargin+contentWidth < flickable.width
  causes widthRatio to be wrongly evaluated to something != 1, whereas it should be 1, because Flickable's defaults at -leftMargin
  (see https://github.com/qtproject/qtdeclarative/blob/5.6/src/quick/items/qquickflickable.cpp#L1592 ).
  and when contentX is -leftMargin, the whole content fits inside the view.
  As a consequence of that, in the current implementation you can also scroll the item from the testcase left and right, which shouldn't be possible (because item+margin are still smaller than the view).

  ============================

  Additional Ubuntu-specific info:
  This is currently blocking the correct implementation of the new scrollbars inside TextFields (ping kalikiana or me (faenil) on IRC for more info)

  ========TESTCASE============

  import QtQuick 2.0

  Flickable {
      id: flickable
      width: 200
      height: 200
      contentWidth: item.width
      contentHeight: item.height
      topMargin: 20
      leftMargin: 40
      Component.onCompleted: console.log("xPos", flickable.visibleArea.xPosition, "widthRatio", flickable.visibleArea.widthRatio)
      Connections {
          target: flickable.visibleArea
          onXPositionChanged: console.log("xPosChanged", flickable.visibleArea.xPosition)
          onWidthRatioChanged: console.log("widthRatioChanged", flickable.visibleArea.widthRatio)
      }
      Rectangle {
          id: item
          width: 100
          height: 100
          color: "black"
      }
  }

  ===========================

  How to reproduce:
  1) qmlscene testcase.qml
  2) watch the console output

  Actual result: widthRatio is != 1
  Expected result: widthRatio == 1

  ===========================

  Fix: I worked on a fix which is being reviewed by upstream --->
  https://codereview.qt-project.org/#/c/161043/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1588238/+subscriptions


Follow ups