796256 - [clock] The Repeat choose page will show up unexpectly

Status: RESOLVED DUPLICATE of bug 793108

(Firefox OS Graveyard :: Gaia, defect)

Description

[GH to BZ]

[GitHub issue by johnshih on 2012-09-13T09:10:20Z, https://github.com/mozilla-b2g/gaia/issues/4686]
## Environment :
Otoro phone, build 2012-09-13
Build info: 
* "gaia" revision= 990890bb77216ce449d8600dae98ff1fea7a6341
* "gecko" revision= 0a501aeb5b9d35a5edf9c256376442dcf4941515

## Repro :
1. Launch the clock app
2. Create a alarm
3. In the alarm edit page, press the "Repeat" column
4. Open the Repeat choose page and press OK button to go back to alarm edit page
5. Press home button to quit
6. Launch the clock app again

## Expected:
* It will show the alarm edit page 

## Actual:
* The Repeat choose page will show up

Comment 1

[GH to BZ]

[GitHub comment by schien on 2012-09-14T11:30:22Z]
@vingtetun : focus event will be triggered again while re-entering alarm app. Therefore, the value selection page will show up if <select> element is the last focused target before app quits. I change the triggering event in forms.js from |focus| to |click| on my local build, and this issue will be resolved. How do you think about this approach?
BTW, listen to |click| event can also allow user to enter value selection page on a already-focused <select> element.

Comment 2

[GH to BZ]

[GitHub comment by sicking on 2012-09-21T16:42:43Z]
So there's a bunch of things I don't understand here, so please bare with me.

I don't think changing from listening to "click" events is the right solution here. That would mean that things don't work if the webpage uses JS to move focus to the select, which is not rare on the web.

Is this happening because the select element still *has* focus when the app is re-entered? If so, it sounds like the platform pieces here is acting correctly because I think that as soon as a select has focus we should show the select UI. And the problem is that the gaia code isn't moving focus away from the select when it should. Somehow...

Or is this happening because despite the select having gotten display:none'ed or otherwise has lost focus, that the platform code is still sending the wrong events causing gaia to show the popup even though the select doesn't have focus.

Comment 3

[GH to BZ]

[GitHub comment by ian-liu on 2012-09-24T03:12:04Z]
Also cc @RudyLu

Comment 4

[GH to BZ]

[GitHub comment by schien on 2012-09-24T03:33:19Z]
@sicking Currently, select element will stay focused after user pickup a value from the selection menu. Therefore, focus event will be triggered on previous focused element again while re-entering app. I add some debug message in forms.js and MozKeyboard.js,  and we can see forms.js receives focus event on select element again in logcat ( http://pastebin.mozilla.org/1839144 , captured while re-entering app).
Do you suggest that we should move focus away from select element after user presses 'ok' or  'cancel' button on selection popup? I found that iPhone will trigger blur event on select element after user pick up a value.

Comment 5

[GH to BZ]

[GitHub comment by sicking on 2012-09-24T04:33:22Z]
Yes, triggering the blur event on selection in the popup sounds like the right solution. That way the "popup is shown" state is always in sync with "select has focus" state.

Does this require changes on the platform side, or can gaia simply call .blur() once the user has made a selection?

Comment 6

[GH to BZ]

[GitHub comment by schien on 2012-09-24T07:03:15Z]
@sicking Gaia cannot retrieve corresponding select element, therefore, I think blur() should be done by Gecko. However, AFAIK, Gecko cannot detect user cancel under current MozKeyboard interface. I've fired bug 793108[1] on bugzilla.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=793108

Comment 7

[John Shih]

Still can reproduce today
build info:
gaia : 2c727ca7ac45b4b054dd41c3d09c303fdcbe581f
mozilla-central : 91fbea5f0a643c661fd9e200041e326bb9870eb7

Comment 8

[Alex Keybl [:akeybl]]

Dupe of bug 793108?

Comment 9

[[e-mail], [e-mail]]

Hi Alex,
Yes, it's duplicated.