Description: When a user attempts to sign into a profile, they will observe that searching will be broken afterwards. The cause appears to stem from a secondary page opening within the Marketplace app, as the user does not have to conclude the sign in process, rather tap 'Sign In' and then close the window: tapping the 'Search' bar at the top will confirm the issue has begun and focus will not transition. The search bar can also be broken if a user begins downloading an app (not recorded). Tapping search does not bring focus. This appears to demonstrate the issue as a seperate window claiming focus from Marketplace, and not returning it properly: albeit no input text fields are available on this window. Repro Steps: 1) Update a Flame to 20150203055641 2) Open the 'Marketplace' app. 3) Tap 'Search' and observe functionality. ** Expected 4) Tap the 'Gear' icon for options/settings. 5) Tap 'Sign In'. 6) Tap the 'X' in the top left corner. 7) Tap 'Search' and observe functionality. ** Actual Actual: The search field does not receive focus and user may not search until the app is reopened. Expected: The search field receives focus and the keyboard is displayed. Environmental Variables: -------------------------------------------------- Device: Flame 3.0 Build ID: 20150203055641 Gaia: ae5a1580da948c3b9f93528146b007fc4f6a712b Gecko: ae5d04409cd9 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 ********************************************* This issue DOES NOT REPRO on flame 2.2 devices: Results: The search field receives focus and the keyboard is displayed. Device: Flame 2.2 BuildID: 20150203002504 Gaia: cd62ff9fe199fb43920ba27bd5fdbc5c311016fc Gecko: 11d93135c678 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 -------------------------------------------------- Repro frequency: 5/5 See attached: video- http://youtu.be/m6P1UtXBJCg logcat

[Blocking Requested - why for this release]: Functional regression of a core feature. Requesting a window.

mozilla-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20150201170935 Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a Gecko: 231a8c61b49f Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 First Broken Environmental Variables: Device: Flame BuildID: 20150201174135 Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a Gecko: bcefc7d8d885 Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Gaia is the same so it's a Gecko issue. Gecko pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=231a8c61b49f&tochange=bcefc7d8d885 Caused by Bug 950934.

Botond, can you take a look at this please. This might have been caused by the work done on bug 950934.

I'm able to repro the issue, looking into it.

Hmm, the tap makes it to TabChild dispatching the synthesized mouse events for it [1]. Not sure what goes wrong from there on... [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/util/APZCCallbackHelper.cpp?rev=c36a026244de#387

I can confirm that backing out bug 950934 fixes the problem. Still not sure why.

The patch in bug 1129526 seems to fix this, suggesting that it's the same issue.