[touch] No way to go to beginning of URL in address bar

Bug #1546346 reported by Michael Terry
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubuntu-ui-toolkit (Ubuntu)
Confirmed
High
Zsombor Egri
webbrowser-app (Ubuntu)
Fix Released
High
Olivier Tilloy

Bug Description

If there is a long URL in the address bar and I want to edit the URL, I can't do it without a mouse or keyboard! Pressing and dragging to the right moves the carrot with my finger to be end of the URL. So far so good.

Doing that same motion but to the left drags the text to the left inside the address bar. Effectively showing my the right side of the URL again! I have no way to go to the beginning, but two ways to get to the end.

Related branches

Olivier Tilloy (osomon)
summary: - [touch] No way to go to beginning of URL in address bat
+ [touch] No way to go to beginning of URL in address bar
Revision history for this message
Olivier Tilloy (osomon) wrote :

I’m not seeing the text being dragged to the left when dragging the cursor to the left, however I can confirm that it’s impossible to move the cursor to the beginning of the address bar.

I initially thought it would be some sort of bug in the TextField component, but I’m not able to reproduce with a simple standalone app, so it must be browser-specific. Needs more investigation.

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Olivier Tilloy (osomon) wrote :

I’ve managed to track down the problem to the x coordinate of the TextField not being an integer. This seems to be a bug in the UITK. I can reliably reproduce the issue with the following standalone example:

import QtQuick 2.4
import Ubuntu.Components 1.3
Item {
  TextField {
    id: textField1
    anchors {
      left: parent.left
      leftMargin: 50
      right: parent.right
      rightMargin: 50
      top: parent.top
      topMargin: 200
    }
    text: "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. Donec et mollis dolor."
  }
  TextField {
    anchors {
      left: parent.left
      leftMargin: 50.1
      right: parent.right
      rightMargin: 50
      top: textField1.bottom
      topMargin: 50
    }
    text: textField1.text
  }
}

While the first text field can be scrolled in both directions without problems, the second one cannot be scrolled to the left.

I’m going to work around the problem in webbrowser-app, but this should probably be addressed in the UITK

Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package webbrowser-app - 0.23+16.04.20160223-0ubuntu1

---------------
webbrowser-app (0.23+16.04.20160223-0ubuntu1) xenial; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Olivier Tilloy ]
  * Remove the 'formFactor' context property, and replace all its uses
    by more meaningful conditions. (LP: #1446904, #1542375)
  * Update translation template.
  * Work around a bug in the UITK that prevents touch scrolling to the
    left of the address bar by ensuring that the x coordinate of the
    text field is an integer. (LP: #1546346)
  * Work around bug #1546677 (UITK), by destroying the bookmark options
    popover instead of hiding it. (LP: #1546627, #1546677)

 -- Olivier Tilloy <email address hidden> Tue, 23 Feb 2016 11:24:49 +0000

Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: nobody → Zsombor Egri (zsombi)
importance: Undecided → High
Revision history for this message
Zsombor Egri (zsombi) wrote :

Olivier, it's more due to text rendering. The x-coordinates, like any other ones cannot be integer values, but perhaps the renderer expects something like that... we have to check that, and may be that a fix would be an integral value... however I doubt that would be the solution.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.