Closed Bug 819619 Opened 12 years ago Closed 9 years ago

To define the final UI behavior of <select> value selector

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:-)

RESOLVED WONTFIX
blocking-b2g -

People

(Reporter: rudyl, Unassigned)

References

Details

Attachments

(1 file)

Background Story
================
Original implementation of <select> value selector
   1. the user click one of the option
   2. press [OK]   -> Gaia system send the value to the <select> element, which trigger the change event.  
                   -> Hide the value selector UI.

After Bug 807418, we changed this to:
Current:
   1. the user click one of the option   ->   Gaia system send the value to the <select> element, which trigger the change event.
   2. press [Close]   ->  only hides the value selector UI without actual value change.

Note:
 The behavior change is not only for resolving Bug 807418, but also make the value selector follow the expected behavior on web, see https://bugzilla.mozilla.org/show_bug.cgi?id=807418#c23 for the discussion. 


Let's discuss the final behavior that is suitable for V1 here.
I also attached a mail thread to discuss, since not all of the messages were forwarded to dev-gaia.
Make this depend on Bug 818359, which is about the appropriate label used in the <select> value selector.
Depends on: 818359
Label should be "OK", not "Close".
QA Contact: jshih
Dear Salva,

Thanks for your input.
As you said in https://bugzilla.mozilla.org/show_bug.cgi?id=818359#c23, the change event would be triggered whenever you click the option. So now it means "Select and confirm".

Please note that there is even no consensus for other well-known mobile OSs.
You could observe different behaviors for <select> value selector on iOS and Android (per my own experiment).

Test
=====
Test page: http://jsfiddle.net/leftlu/c6Gsr/11/

1. for single select: 

  iOS: change event would occur after you select an option and then click [Done].
Android: change event would occur after you select an option. 

2. for multiple select:
  iOS: change event would occur after you select an option.
  Android: change event would occur after you select an option and then click [Done].

iOS: Safari on iOS 5
Android: built-in browser on Android 4.0.3
=====

That's why I think we should gather all thoughts, including both UX and devs here.
Blocks: 821155
(In reply to Rudy Lu [:rudyl] from comment #4)
> Dear Salva,
> 
> Thanks for your input.
> As you said in https://bugzilla.mozilla.org/show_bug.cgi?id=818359#c23, the
> change event would be triggered whenever you click the option. So now it
> means "Select and confirm".
> 
> Please note that there is even no consensus for other well-known mobile OSs.
> You could observe different behaviors for <select> value selector on iOS and
> Android (per my own experiment).
> 
> Test
> =====
> Test page: http://jsfiddle.net/leftlu/c6Gsr/11/
> 
> 1. for single select: 
> 
>   iOS: change event would occur after you select an option and then click
> [Done].
> Android: change event would occur after you select an option. 
> 
> 2. for multiple select:
>   iOS: change event would occur after you select an option.
>   Android: change event would occur after you select an option and then
> click [Done].
> 
> iOS: Safari on iOS 5
> Android: built-in browser on Android 4.0.3
> =====
> 
> That's why I think we should gather all thoughts, including both UX and devs
> here.

Android behavior seems more correct to me.
QA Contact: jshih → whsu
There's also a problem when you want to preview the selection, like the way it happens when the user selects a ringtone.

FMPOV it should be possible for the user to select the desired ringtone, hear a preview of it, and then tap "Ok" to make the selection or "Cancel" to close the value selector w/o doing any change.

We should provide a way to select something from a list and then confirm the selection, or leave the selection screen with a "Cancel", no matter the user already chose an item, without making changes.
Please try bug 897303 patch, I think we need fix this bug because it cause bad user experience.
blocking-b2g: --- → koi?
Not a blocker - this issue has been around since 1.01, not needed for 1.2.
blocking-b2g: koi? → -
(In reply to James Zhang from comment #8)
> Please try bug 897303 patch, I think we need fix this bug because it cause
> bad user experience.

Its too late in the 1.2 time frame to resolve this, hence I am going to nominate it for 1.3 so we can fix in future releases
blocking-b2g: - → 1.3?
This isn't happening for 1.3 - we're closing out what features were taking on for 1.3 for systemsfe. blocking-
blocking-b2g: 1.3? → -
Component: Gaia::System → Gaia::System::Window Mgmt
seems newly selector UI is defined http://gaia-components.github.io/gaia-components/
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: