Closed Bug 1089542 Opened 5 years ago Closed 5 years ago
Search in Browser app is not working - tapping enter after the URL was added has no effect
The user is not able to go to a certain website in Browser app, tapping enter after the URL has no effect. Prerequisities: Make sure your device has internet connection, wifi or cell data. Repro Steps: 1. Launch Browser app 2. Type an URL (E.g: https://www.mozilla.org/) 3. Tap Enter Expected: The user is redirected the correct website Actual: Tapping Enter has no effect; the user is not redirected to the page it was supposed to. Repro frequency: 5/5 Regression range, based on b2g-inbound builds: Last working: Device firmware (date) 24 Oct 2014 14:40:36 Device firmware (incremental) eng.cltbld.20141024.174026 Device firmware (release) 4.4.2 Device identifier flame Gaia date 24 Oct 2014 13:14:45 Gaia revision 649d0ace7360 Gecko build 20141024133311 Gecko revision 90da527e35da Gecko version 36.0a1 First failing: Device firmware (date) 24 Oct 2014 15:46:16 Device firmware (incremental) eng.cltbld.20141024.184606 Device firmware (release) 4.4.2 Device identifier flame Gaia date 24 Oct 2014 13:14:45 Gaia revision 649d0ace7360 Gecko build 20141024150913 Gecko revision e8a6f40728b7 Gecko version 36.0a1 Gaia diff: None Gecko diff: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=90da527e35da&tochange=e8a6f40728b7 This issue is reproducible on v2.2, but it is not reproducible on v2.1. This is causing failures in lots of our automated tests: http://jenkins1.qa.scl3.mozilla.com/job/flame-kk-319.b2g-inbound.ui.functional.smoke/748/HTML_Report/ Traceback (most recent call last): File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/.env/local/lib/python2.7/site-packages/marionette_client-0.8.4-py2.7.egg/marionette/marionette_test.py", line 264, in run testMethod() File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/tests/functional/browser/test_browser_cell_data.py", line 29, in test_browser_cell_data browser = search.go_to_url('http://mozqa.com/data/firefox/layout/mozilla.html') File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/apps/search/app.py", line 27, in go_to_url return search_panel.go_to_url(url) File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/apps/homescreen/regions/search_panel.py", line 39, in go_to_url self.wait_for_condition(lambda m: urllib.quote(url, safe=':/?=') in self.apps.displayed_app.name) File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 56, in wait_for_condition Wait(self.marionette, timeout).until(method, message=message) File "/var/jenkins/2/workspace/flame-kk-319.mozilla-central.ui.functional.smoke/.env/local/lib/python2.7/site-packages/marionette_client-0.8.4-py2.7.egg/marionette/wait.py", line 143, in until cause=last_exc) TimeoutException: TimeoutException: Timed out after 30.2 seconds
We should get a regression range based on mozilla-inbound builds.
Regression range, based on mozilla-inbound builds: Last working: Gaia-Rev d893a9b971a0f3ee48e5a57dca516837d92cf52b Gecko-Rev https://hg.mozilla.org/integration/mozilla-inbound/rev/e94b66dca22c Build-ID 20141024060609 Version 36.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141024.093351 FW-Date Fri Oct 24 09:34:01 EDT 2014 Bootloader L1TC00011880 First failing: Gaia-Rev 29ed78a26d62b58f663437a45f273d57b9781d79 Gecko-Rev https://hg.mozilla.org/integration/mozilla-inbound/rev/e981fd5453dc Build-ID 20141024081211 Version 36.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141024.113209 FW-Date Fri Oct 24 11:32:19 EDT 2014 Bootloader L1TC00011880
I found a more accurate regression range: Last good: Device firmware (date) 24 Oct 2014 06:34:01 Device firmware (incremental) eng.cltbld.20141024.093351 Device firmware (release) 4.4.2 Device identifier flame Gaia date 23 Oct 2014 13:55:40 Gaia revision d893a9b971a0 Gecko build 20141024060609 Gecko revision e94b66dca22c Gecko version 36.0a1 First Bad: Device firmware (date) 24 Oct 2014 07:01:21 Device firmware (incremental) eng.cltbld.20141024.100111 Device firmware (release) 4.4.2 Device identifier flame Gaia date 23 Oct 2014 13:55:40 Gaia revision d893a9b971a0 Gecko build 20141024064811 Gecko revision da49be9b1139 Gecko version 36.0a1 Gecko diff: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e94b66dca22c&tochange=da49be9b1139
Kershaw, could this have been caused by one of your changes in bug 1020172?
Component: Gaia::Browser → Gaia::System::Browser Chrome
[Blocking Requested - why for this release]: Will prevent people finding pictures of cats.
blocking-b2g: --- → 2.2?
Duplicate of this bug: 1089630
Whiteboard: [fromAutomation] → [fromAutomation][systemsfe]
It seems to be a device-only bug.
Chatted with khuey, pretty confident this was caused by bug 1020172. Wouldn't be caught by our integration tests because they only run in-process. Have requested backout by RyanVM.
I backed out bug 1020172 in https://hg.mozilla.org/mozilla-central/rev/08ad036e00fe but it won't make a b2g nightly build until the one that starts building in 11 hours. The one that started building an hour ago does not have the backout.
Hi Martijn, I've provided a revised patch in bug 1020172 comment #97. Could you help to also verify this at your side? Thanks.
We have a m-i build in our automation and I can confirm that the blackout has worked. The build with the back out is: Device firmware (date) 27 Oct 2014 14:07:56 Device firmware (incremental) eng.cltbld.20141027.170745 Device firmware (release) 4.4.2 Device identifier flame Gaia date 27 Oct 2014 10:43:23 Gaia revision 6a7fb482a03c Gecko build 20141027181024 Gecko revision ecf4df03029a Gecko version 36.0a1
Thanks, this should be fixed now. Just needs verifying in the next nightly build.
Assignee: nobody → bfrancis
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Verified fixed in the latest Flame 2.2 build. Typing a URL into the Rocketbar in Browser properly navigates the Browser to the webpage. Environmental Variables: Device: Flame 2.2 Master BuildID: 20141028040202 Gaia: 6a7fb482a03c5083ef79b41e7b0dfab27527cd04 Gecko: a255a234946e Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89 Version: 36.0a1 (2.2 Master) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
This bug is still being reported on Flatfish, any idea why this change might not have made it into Flatfish builds yet?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Hi Ben, Currently, I don't have any idea. Can you confirm this is caused by bug 1020172? I think there must be another cause. Thanks.
As I previously opened the duplicate bug 1091606 concerning the Flatfish tablet, I report that I am not experiencing it in the latest build of Flatfish 20141111.
Looks like this got fixed.
You need to log in before you can comment on or make changes to this bug.