1020403 - View URL web activity in navigate method not working

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Search, defect)

Description

[Ben Francis [:benfrancis]]

STR:
* Enable homescreen 2
* Type a URL into homescreen search and hit enter

Expected:
* Loads URL

Actual:
* Nothing

Comment 1

[Kevin Grandon :kgrandon]

This is interesting... E/GeckoConsole( 3585): Can only start activity from user input or chrome code

I assume this is because we send an IAC message to launch the activity? We definitely need to add an integration test for this and get this turned on for TBPL.

Comment 2

[Kevin Grandon :kgrandon]

After looking at this some more, it appears that the cancel button is getting a click event first, sending the search app to the background. This happens even though the search bar definitely has focus. I think this is possibly a bug in keyboard perhaps? 

I'm doing a ni? on rudy and tim to see if they know any recent keyboard changes that would cause click events or other focus problems.

Comment 3

[Jason Smith [:jsmith]]

Was this ever working? Just wondering if this is a regression or not.

Comment 4

[Kevin Grandon :kgrandon]

Yup, it was definitely working before. Adding the regression keyword, but feel free to tag it up however you see fit :)

Comment 5

[Jason Smith [:jsmith]]

Note for the window here - you'll need to bisect this using eng. builds with the vertical homescreen enabled.

Comment 6

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

AFAIK, we did not change anything around sending the 'Enter' key recently.
At a first glance, I think this issue is about pressing 'Enter' key in a form would trigger the click event of the first button in a form.

Have we changed the HTML structure or the key event handling in the search app recently?

Comment 7

[Ben Francis [:benfrancis]]

Interesting, does that not happen for reset buttons?

If not, then it could have been caused by the type attribute change in bug 1015923.

Is there a way to prevent the event getting fired on the button. We are already doing e.preventDefault();

Comment 8

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/20074

Aha, type=button :)

Comment 9

[Dale Harvey (:daleharvey)]

Comment on attachment 8434913 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20074

Aww crap, apologies, now that homescreen is enabled we can get the integrations tests back on that would have caught this, but best get this fixed and I / we can get some better tests in soon

Comment 10

[Ben Francis [:benfrancis]]

https://github.com/benfrancis/gaia/commit/ab6a47fcb551d0ebd40554ac2f06574c4c7f47ac

Comment 11

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Ben Francis [:benfrancis] from comment #7)
> Interesting, does that not happen for reset buttons?
> 
> If not, then it could have been caused by the type attribute change in bug
> 1015923.
> 
> Is there a way to prevent the event getting fired on the button. We are
> already doing e.preventDefault();


To my understanding, this is because "submit" is the default value for a button's type attribute, if you don't specify type for a button.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Attributes

:)

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

tried with www, http://www., https://www..
There's a bug on the transition being smaller before.  See bug 1026287

Gaia      82e957160ca017087bd374cd051339e55b641e68
Gecko     https://hg.mozilla.org/mozilla-central/rev/f78e532e8a10
BuildID   20140619040201
Version   33.0a1
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014