856931 - [Settings] In Brightness menu, the adjust value is not updated sometimes from DOM event when control silder bar.

Status: RESOLVED DUPLICATE of bug 863164

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

Description

[Leo]

1. Title : In Brightness menu, silder bar moves quickly and then can't set the adjusted value sometimes.
2. Precondition : 
3. Tester's Action : Settings - Display - Brightness - silder bar moves quickly from left to right and revers.
4. Detailed Symptom (ENG.) : Can't set the adjusted value. Keep the previous setting value.
5. Expected : Apply the adjusted value
6. Reproducibility: Y
1)Frequency Rate : sometimes
7. Mozilla build ID : 20130318070202

In that case, do not dispatch handleEvent in Settings.js
Refer to the attaced video file.

Comment 1

[Leo]

Attachment: video file

Comment 2

[Leo]

Attachment: video file (control the slide bar normally)

Comment 3

[Leo]

Gaia\apps\settings\js\settings.js
In handleEvent: function settings_handleEvent(event)function
Wrong event.target.value is passed.

Comment 4

[Alex Keybl [:akeybl]]

Please reassign if you're overloaded kaze

Comment 5

[Fabien Cazenave [:kaze]]

I can work on this as soon as my TEF+ bugs are clear.

Comment 6

[Fabien Cazenave [:kaze]]

This bug is difficult to reproduce. It seems like it only happens when sliding the control (everything seems to work fine when tapping directly).

Comment 7

[Fabien Cazenave [:kaze]]

OK, here’s how to reproduce it. 

 • open the Settings > Display panel
 • uncheck “adjust automatically”
 • move the throbber

If the throbber is released over the slider, everything works fine.
If the throbber is released out of the slider (e.g. keep the finger down and slide to the bottom of the screen), the throbber moves properly but the value is not updated accordingly.

See apps/settings/js/utils.js — we listen to the `mouseup' event on the slider itself and nothing more.

Comment 8

[Dale Harvey (:daleharvey)]

Just an update, this is only reproducable on v1.0.1, central has native range input it looks like. The mouseup that kaze identified is the problem, will have a patch in the morning as it needs more than just that changed to fix

Comment 9

[Dylan Oliver [:doliver]]

Is the coming patch for 1.0.1, i.e. should this be sent to tef? instead?

Comment 10

[Dale Harvey (:daleharvey)]

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

Comment 11

[Dale Harvey (:daleharvey)]

This can be applied to master, but it only fixes the bug on v1.0.1 (and any branch that doesnt have the native range inputs)

Comment 12

[Dylan Oliver [:doliver]]

Leo, can you re-test this on v1-train? It sounds like it is no longer reproducible there.

Comment 13

[hyuna.cho]

I had tested this bug but I can't reproduce anymore.
plz land.

Comment 14

[Evelyn Hung]

Comment on attachment 743016 [details]
https://github.com/mozilla-b2g/gaia/pull/9452

redirect to Arthur

Comment 15

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 743016 [details]
https://github.com/mozilla-b2g/gaia/pull/9452

Dale, thank you for the effort. The patch enables users drag the thumb outside of the slider, which is great. However, the panel also moves vertically when dragging.

The patch of bug 863164 was just landed, which removed mouse_event_shim and also fixed the bug without the side effect of vertical movement. I would suggest we simply uplift it to v1-train.

Comment 16

[Dale Harvey (:daleharvey)]

Agreed, just tested and the new range polyfill works great without needing patched

Comment 17

[John Ford [:jhford] CET/CEST Berlin Time]

I am not sure what needs to happen.  Do we want to apply https://github.com/daleharvey/gaia/commit/33a06bd3bd07e6d61c4c2dfbb4e67ec846518289 to v1.0.1?  This is not yet landed on master.  I'm not sure what needs to happen here.

Comment 18

[Dale Harvey (:daleharvey)]

Ah sorry, nothing needs to happen since it was resolved separately, that bug is in the process of being uplifted

Comment 19

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Dale Harvey (:daleharvey) from comment #18)
> Ah sorry, nothing needs to happen since it was resolved separately, that bug
> is in the process of being uplifted

Thanks for the update!  Can you either mark this bug as a dupe or set the status-b2g18 flag to 'fixed' when the other bug is uplifted please?

Comment 21

[Dale Harvey (:daleharvey)]

Unassigning myself from a dup bug