Using search in the header can sometimes have a text field from a different tab

Bug #1341814 reported by Andrew Hayzen
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubuntu-ui-toolkit (Ubuntu)
Fix Released
High
Giulio Collura
Vivid
New
Undecided
Unassigned
ubuntu-ui-toolkit (Ubuntu RTM)
New
Undecided
Unassigned

Bug Description

In the linked branch there are two pages inside separate tabs. Both have searching enabled, when something is entered in the textfield the same text should appear in the label within the page. However upon switching between the tabs and using the textfield sometimes it appears as if the textfield from the other tab is shown as no text appears in the label (also note the tracing in the debug output).

Test Plan:
Select search
Select text field
Enter Te
* Check Te appears in label
Select back
Switch to World
Select search
Select text field
Do no enter anything
Select back
Switch to Hello
Select search
Select text field
Enter Te
* Notice label is not updated
** Repeat switching between tabs and entering data in the text field if the issue doesn't occur first time **

Related branches

Changed in ubuntu-ui-toolkit:
status: New → Confirmed
Tim Peeters (tpeeters)
Changed in ubuntu-ui-toolkit:
assignee: nobody → Tim Peeters (tpeeters)
importance: Undecided → High
Tim Peeters (tpeeters)
Changed in ubuntu-ui-toolkit:
importance: High → Critical
Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :

Is there an ETA for when this might be fixed? It's blocking a long-standing merge to the music app.

Tim Peeters (tpeeters)
Changed in ubuntu-ui-toolkit:
importance: Critical → High
Tim Peeters (tpeeters)
Changed in ubuntu-ui-toolkit:
status: Confirmed → In Progress
Revision history for this message
Tim Peeters (tpeeters) wrote :

I cannot reproduce, updates seem correct. Did it get fixed?

What I do notice is that when I follow the exact steps that you describe, when I go back to the first tab and click search, even though it works fine, the other textfield is still visible semi-transparent behind the text that I am typing. (so the "search..." text is visible behind the text that I am typing).

Revision history for this message
Tim Peeters (tpeeters) wrote :

The behavior that the previous textfield is visible through the current one that I described in my previous comment is fixed when I remove "searchfield.focus = true" from l.22 in CustomPage.qml of the test program branch.

Revision history for this message
Tim Peeters (tpeeters) wrote :

the textfield on the first page doesn't get focus the first time I click on the search icon. I have to tap on the textfield before I can type. After that, it is possible to type immediately after clicking the search button (all this is on desktop).

Revision history for this message
Nekhelesh Ramananthan (nik90) wrote :

This afternoon, I was switching Flashback to using search on headers and now I face this issue as well. The search textfield lingers from the "search" state even when switching to another tab or pushing a page into a pagestack. Although here is the kicker, in the search mode, we use contents: TextField{}, and I have used head.contents throughout the app to set the title of a page and I don't see the issue of the page title leaking into other pages.

So I suspect the core issue lies with PageHeadState{}. Somehow switching between "Search" to "Default" PageHeadState isn't done properly or something.

Flashback like Music app is made up of several tabs and pages and this issue was easy to hit. I don't see this issue in the clock app or addressbook because they have a very simple navigation structure.

Revision history for this message
Tim Peeters (tpeeters) wrote :

I have been able to reproduce the bug using the long list of steps in the bug report, but I couldn't reproduce it with a simple test program. If anyone can help with that, that would be helpful.

I am working on another issue (new list items) now but I will get back to this bug as soon as possible.

Zoltan Balogh (bzoltan)
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: nobody → Tim Peeters (tpeeters)
importance: Undecided → High
status: New → In Progress
Zoltan Balogh (bzoltan)
no longer affects: ubuntu-ui-toolkit
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: Tim Peeters (tpeeters) → Giulio Collura (gcollura)
Changed in ubuntu-ui-toolkit (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Tim Peeters (tpeeters) wrote :
Revision history for this message
Tim Peeters (tpeeters) wrote :

It is fixed now in vivid. A possible workaround if you run a pre-vivid version is here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1400297/comments/4

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-ui-toolkit - 1.1.1376+15.04.20150111-0ubuntu1

---------------
ubuntu-ui-toolkit (1.1.1376+15.04.20150111-0ubuntu1) vivid; urgency=medium

  [ Tim Peeters ]
  * Add a preview of the new list items to the UITK component gallery.

  [ Zoltan Balogh ]
  * Update the test plan and fix the PPA string in case it contains backslash.
  * Added Dialog CPO to test if OSK pushes up the the dialog.

  [ Zsombor Egri ]
  * ListItem highlight is driven also by the connection of a slot to
    the clicked() signal. This will also be applied when pressAndHold
    signal will be introduced. Fixes LP: #1399025

  [ Giulio Collura ]
  * Force the removal of the previous 'contents' item by removing its parent.
    This way we ensure that the contents are correctly hidden, focused and
    removed, without destroying them. Fixes LP: #1341814 LP: #1400297
 -- Ubuntu daily release <email address hidden> Sun, 11 Jan 2015 18:57:02 +0000

Changed in ubuntu-ui-toolkit (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Tim Peeters (tpeeters) wrote :

The bug is still present in RTM. There is a workaround here (thanks gcollura and nik90):

http://paste.ubuntu.com/10609646/

Since we are switching rtm to vivid soon, it is probably not worth the effort to backport the fix.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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