1063434 - [Dophin][FM]The background of bookmark-button cannot change normally.

Status: RESOLVED WONTFIX

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

Description

[Chaochao Huang]

Attachment: the video of issue

STR：
1、Open the FM app.
2、click the bookmark-button many times.

OBSERVED:
3. The background of bookmark-button cannot change normally and the frequency cannot be saved.

EXPECTED:
4.The background of bookmark-button can change normally and the frequency can be saved.

Comment 1

[Chaochao Huang]

There are three different states in the process of clicking bookmark-button.

#bookmark-button {
  background: url("images/toggle-fav-star-off.png") no-repeat center center / 4rem;
}

#bookmark-button:active,
#bookmark-button[data-bookmarked="true"]:active {
  background: #00ABCD url("images/toggle-fav-star-pressed.png") no-repeat center center / 4rem;
}

#bookmark-button[data-bookmarked="true"] {
  background: url("images/toggle-fav-star-on.png") no-repeat center center / 4rem;
}

The state of bookmark-button still is 'bookmark-button:active' after leaving the bookmark-button, which results in the issue of the background of bookmark-button unable changing normally.

Comment 2

[Chaochao Huang]

Dear ehung,
 The issue is still exist when we delete patches of spreadtrum. Plz help analyze of the issue.Thank you~

Comment 3

[Jason.Liu]

Dear Rachelle & Wayne,

Plz help to check this issue.

Comment 4

[ying.xu]

what‘s behavior of flame for this bug?

Comment 5

[yong.ren]

(In reply to ying.xu from comment #4)
> what‘s behavior of flame for this bug?

flame also have this problem.

Comment 6

[Wayne Chang [:wchang]]

Jason,

Can your team analyze this first? 
This is going to be a low priority bug for us seeing this repro step is not a sensible use case.

(In reply to Chaochao Huang from comment #0)
> Created attachment 8484874 [details]
> the video of  issue
> 
> STR：
> 1、Open the FM app.
> 2、click the bookmark-button many times.
>

Comment 7

[Rachelle Yang [:ryang][[e-mail]]]

Hi Jason, please kindly analyze the issue at your side first.Besides, if possible please provide the occurrence rate and which build you are testing on . Thanks!

Comment 8

[Chaochao Huang]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #7)
> Hi Jason, please kindly analyze the issue at your side first.Besides, if
> possible please provide the occurrence rate and which build you are testing
> on . Thanks!

When you click bookmark-button continuously, the occurrence rate is 100%. We test on V1.4.

Comment 9

[Chaochao Huang]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #7)
> Hi Jason, please kindly analyze the issue at your side first.

Dear Rachelle, the issue cannot be solved in GAIA. Analyze as below，

There are three different states in the process of clicking bookmark-button.
1）#bookmark-button {
  background: url("images/toggle-fav-star-off.png") no-repeat center center / 4rem;
}
2）#bookmark-button:active,
#bookmark-button[data-bookmarked="true"]:active {
  background: #00ABCD url("images/toggle-fav-star-pressed.png") no-repeat center center / 4rem;
}
3）#bookmark-button[data-bookmarked="true"] {
  background: url("images/toggle-fav-star-on.png") no-repeat center center / 4rem;
}
The state of bookmark-button still is 'bookmark-button:active' after leaving the bookmark-button, which results in the issue of the background of bookmark-button unable changing normally.I think it is issue of Gecko's mechanism.

It will be highly appreciated if you can analyze the issue and give us some advice.

Comment 10

[Evelyn Hung]

Hi Yi-fan,

Could you please help on this case? From comments above, it seems either (1)touch event didn't be fired correct so the CSS rule didn't applied, or (2) The CSS rule applied but nothing happen. Please identifying which one is the cause so we can find correct Gecko dev. Thanks!

Comment 11

[yifan [:yifan][:yliao]]

Yes, will try to figure it out shortly.

Comment 12

[yifan [:yifan][:yliao]]

Attachment: a web test page for touch & click events

Confirmed that the CSS :active state of the button is not handled correctly. When tapping the bookmark button repeatedly there is a certain chance that a click event is not triggered, and at the same time the :active state of the button is not removed. This also happens on flame.

This might be a gecko or hardware bug. Please try the web page on mobile devices if interested.

flame version:
Gaia      72262d054ffa5d0d2b5a0033f713149281511aea
Gecko     https://hg.mozilla.org/mozilla-central/rev/4f2cac8d72da
BuildID   20140917160215
Version   35.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014

Comment 13

[Chaochao Huang]

(In reply to Yi-Fan Liao [:yifan][:yliao] from comment #12)
> Created attachment 8491361 [details]
> a web test page for touch & click events
> 
> Confirmed that the CSS :active state of the button is not handled correctly.
> When tapping the bookmark button repeatedly there is a certain chance that a
> click event is not triggered, and at the same time the :active state of the
> button is not removed. This also happens on flame.
> 
> This might be a gecko or hardware bug. Please try the web page on mobile
> devices if interested.

Dear Yi-Fan,
  Is there any good method for this issue, or some advice for this issue? Thanks.

Comment 14

[yifan [:yifan][:yliao]]

The web page is an easier way to replicate the CSS :active and click event not triggered issue, either on Dolphin or flame. Use it to reproduce the bug by tapping 'test test test'.

In the fm app on flame you still can but not easy to reproduce this bug. Seems better hardware mitigates the issue.

Comment 15

[Chaochao Huang]

> 
> In the fm app on flame you still can but not easy to reproduce this bug.
> Seems better hardware mitigates the issue.

I donot think better hardware mitigates the issue. Tarako's hardware is worse than Dophin's, but this issue only exists on Dophin. It might be a gecko bug about states ofthe CSS :active changing. Dear ehung, could you help find related person to check this issue? Thanks.

Comment 16

[Evelyn Hung]

(In reply to Yi-Fan Liao [:yifan][:yliao] from comment #12)
> Created attachment 8491361 [details]
> a web test page for touch & click events
> 
> Confirmed that the CSS :active state of the button is not handled correctly.
> When tapping the bookmark button repeatedly there is a certain chance that a
> click event is not triggered, and at the same time the :active state of the
> button is not removed. This also happens on flame.
> 

Maybe we can start from looking why the click event wasn't dispatched correctly.

Viral, not sure if you have bandwidth to take a look here. Thanks.

Comment 17

[viral [:viralwang]]

the missing "click" event is really easily reproduce with APZ enable.

Hi Kats, it looks like another APZ relative bug, any input we can have?

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Attachment: a web test page for touch & click events

Inlining test-case into the attachment

Comment 19

[Kartikaya Gupta (email:[e-mail])]

I don't have a device that can reproduce this with me at the moment, so it'll have to wait until Monday. Leaving needinfo for now.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Whoops.

Comment 21

[Kartikaya Gupta (email:[e-mail])]

So I used the test page to reproduce the issue. The only time I don't see a click event get generated is when I do a double-tap action (that is, two taps in quick succession). I see the same behaviour on the test page in Firefox for Android and Chrome for Android. I don't think this is a bug, it's expected behavior. The double-tap gesture is a separate gesture from click and so doesn't generate a click event.

I wasn't able to reproduce the problem on the test case where the active highlight get stuck, but we do have other bugs on file for similar issues. We are waiting for a UX spec (bug 1009684) before we fix that as there are many interactions where it is not clear what we should be doing.

Comment 22

[viral [:viralwang]]

Hi Kats,

Just figure out this bug can only found in v2.0.
Gaia-Rev        ddb7567c60b31dbcb27817f8c126bbba8dccb63b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e3545ca967ae
Build-ID        20140930160202
Version         32.0

Looks like I can NOT reproduce it in master branch? Any idea about this?
Gaia-Rev        77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2ae57957e4bb
Build-ID        20140930160207
Version         35.0a1

Comment 23

[Mingyan Liu]

There are other testing steps to reproduce the same problem:

1. Enter FM Radio, click book-mark icon to collect more than two frequencis.
2. Immediately click the collected frequency after clicking speaker icon 

result:

1. The frequency's state is always selected, and cannot change.

Comment 24

[Mingyan Liu]

Attachment: VID_20141001-for comment 23.mp4

Attachment added for comment 23.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Viral - if the bug exists only on 2.0 and not on master, it is probably worth getting a fix window to see what fixed it, and see if that can be safely uplifted. I don't know if it's worth doing a local 2.0 build and debugging on that when we know the issue is already fixed.

Mingyan - Thanks for the additional video. I'm not able to reproduce that on a master build - is what you saw restricted to 2.0? Note also that I'm only concerned about actual clicks not triggering actions (it looks like that happens in your video); if the bug is only the visual highlight effect then I want bug 1009684 to be resolved before I make any changes on that front.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

I just tracked down a fix for bug 1068571 which might also fix the issue you're seeing here, if you're seeing it on master. Specifically, sometimes clicks are ignored (and the item is left in a highlighted state) in some cases if the previous click had a small velocity. The velocity would not be obvious to the user but it gets saved in the code and ends up canceling the next click. That bug was a regression from bug 1039979 which is on 2.1 and up, so it would not explain behaviour on 2.0.

Comment 27

[viral [:viralwang]]

Hi Kats,

I found the commit changes the behaviour of click button in FM in master branch.
I can can't reproduce it in flame

commit e7190ff526ced6d6bf7ad5fc2e999dd7d3121e69
Author: Kartikaya Gupta <[e-mail]>
Date:   Wed Jul 16 08:33:50 2014 -0400

    Bug 1009733 - Rewrite much of the APZC input block handling code. r=botond

is that possible to merge this patch to 2.0 or 1.4 for testing in other devices also?
thanks!

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Unfortunately that bug (and dependencies) involve a lot of code changes and are too risky to uplift.

Comment 30

[Evelyn Hung]

Set 2.0M? for triage.

Comment 31

[Francis Lee [:frlee]]

Triage: this is not Woodduck's blocker and low user impact. it is too risky since it involves too much change

Comment 32

[Josh Cheng [:josh]]

per comment 31