Closed Bug 889138 Opened 11 years ago Closed 11 years ago

[B2g][music][search] Unable to access keyboard in the music app often when using the Search feature.

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:leo+)

VERIFIED DUPLICATE of bug 874754
blocking-b2g leo+

People

(Reporter: croesch, Assigned: squib)

References

Details

(Keywords: regression, Whiteboard: leorun4)

Attachments

(2 files)

Attached image Missing Keyboard (deleted) —
Description: When trying to use the music apps Search feature, if you try to access search in multiple music tabs, the search feature will not have a keyboard present which causes the user not be to able to use the search feature at all. Seems the only time you will get the keyboard is in the first tab music tab you try to search. After that any other tab you go to (artist,album etc..) will not have a keyboard. Repro Steps: 1) Updated to Leo Build ID: 20130625070217 2) Put some music on the test device 3) Launch the music app. 4) On any music tap drag downwards with your finger to access the Search feature and notice you will see a keyboard. 5) Close the search feature and switch to a new music tab such as Artist view. 6) Again pull down the search feature and notice that there is no keyboard present to search music with. Actual: When trying to search music, trying multiple music tabs will not have a keyboard present when the search window appears. Expected: Search should always contain a keyboard in any tab the user tries to search in. Environmental Variables Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db Gaia: 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c Platform Version: 18.1 Notes: Repro frequency: 100% Test Suite Name: Music UCID: music-019 Link to failed test case: https://moztrap.mozilla.org/runtests/run/1600/env/314/?&pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=3694&filter-suite=124 Q Analysts Team Priority: Pri 2 See attached: Screenshot, logcat
Not seeing this specific behavior on Leo device using updated base image and: Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/15923aca6e6d Gaia c7472acec84f0d4527cdd6fd555d289e1d3e1d1d BuildID 20130701070213 Version 18.0 For me there is only one tab that consistently does not show the keyboard, and that is the music tab. Playlist, Artists, Albums and Songs all show the keyboard when I start to type letters into the search field.
Attached file Log of music search event (deleted) —
Whiteboard: leorun4
I also reproduced this issue by using today's pvt build, not sure why keyboard is not invoked. CCing Rudy and he might have some ideas on this.
I found while testing that for me it depends on where you start the search - if I start with the music tab, it finds the keyboard. The very next tab I select the keyboard is missing. However, if I start with songs and work backwards, all the tabs show the keyboard except the music tab.
Hi, After checking keyboard app, in this case (clicking the 2nd search input), keyboard app would get focuschange event to bring up the keyboard. https://github.com/mozilla-b2g/gaia/blob/5bf9d534c17567e54e3d5b71af5065a78f95865b/apps/keyboard/js/keyboard.js#L413 We need to investigate Gecko implementation, such as forms.js and mozKeyboard part.
Component: Gaia::Music → General
Nomming for leo, as this affects use of the music app (essentially rendering search unusable).
blocking-b2g: --- → leo?
John, is this a regression? How well has this feature ever worked? Unless this is different behaviour than in v1.0.1 it's likely not something we can block on.
Flags: needinfo?(jhammink)
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #7) > John, is this a regression? How well has this feature ever worked? Unless > this is different behaviour than in v1.0.1 it's likely not something we can > block on. Music search is a 1.1 feature. So this is a bug affecting a 1.1 feature. This really can't be compared using a 1.0.1 analysis wise if this is targeting 1.1 use cases specifically. I can confirm I can reproduce this as well.
This potentially be consistent STR btw for what's seen in bug 890787.
Looks like Fabrice confirmed this is a dupe of the intermittent regression in bug 890787. Which then confirms this is indeed a keyboard regression.
Flags: needinfo?(jhammink)
Over to Hema, as this is a fairly major issue in a new feature.
Assignee: nobody → hkoka
blocking-b2g: leo? → leo+
This is a regression, since I cannot reproduce this with an old build of Unagi, Build ID: 20130613230207 Gecko revision: b300478ccf6859fa388ad3ae369793648557be01 Trying to find the regression window.
Keywords: regression
Jim, Please take a look at this one? Thanks Hema
Assignee: hkoka → squibblyflabbetydoo
I'll take a look at this. A regression window would be very helpful for me, since I'm guessing this is an issue in the keyboard, not the music app, and I know very little about how the keyboard works.
QA Contact: mozillamarcia.knous
I think this regression is caused by Bug 860546. If I revert Bug 860546 (& Bug 882866, a follow-up), this issue would not occur.
Rudy, thanks for your help. Bug 860546 is the cause of this regression, but not the root cause. The root is Bug 874754 which blocks Bug 860546. A fix will land soon.
No longer blocks: 860546
Blocks: 877024
Any info on when a fix for this might land? It's important for our YouTube certification.
When Bug 874754 is fixed, this bug will be resolved. We have already made a patch, but it still needs a few days. Please see Bug 874754 for details.
I'm going to dupe over to bug 874754 then since that's the bug tracking the fix. I'll also nom it to block then given that we now confirm fixing that bug is required to address the keyboard issues in this bug.
No longer blocks: 877024
Status: NEW → RESOLVED
Closed: 11 years ago
No longer depends on: 874754
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: