Closed Bug 944898 Opened 11 years ago Closed 11 years ago

[Music] With APZ turned on clicks on the music app seems wrong

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 940706

People

(Reporter: vingtetun, Unassigned)

References

Details

With APZ turned on clicking on the buttons at the bottom of the music app does not work anymore, and instead it seems like the click is dispatched to the underlying scrollable list. Steps to reproduce: - Populate data on the device by |cd $GAIA; make reference-workload-medium| with the device plugged in. - Open the music app - click on one of the button at the bottom of the screen Expected result: - The view change to the one corresponding to the targetted button Actual result: - A song starts playing.
One strange thing I'm seeing with that is that click events on this area for this app always goes via http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#780 with a wrong y coordinate where click usually goes through http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#766.
I wonder if we trigger the 'confirmed' code path because there is a scrollable list underneath ? The same code path is visible for music, gallery and email who all use this pattern of a semi-transparent area covering part of the scrollable list. The coordinate are correct there though so this is probably unrelated (but i need to check if that does not mean that the events are delayed of 300ms for that - likely a separate issue).
(In reply to Vivien Nicolas (:vingtetun) (:21) (RTO - Review Time Off until 09/12/13) from comment #2) > I wonder if we trigger the 'confirmed' code path because there is a > scrollable list underneath ? The same code path is visible for music, > gallery and email who all use this pattern of a semi-transparent area > covering part of the scrollable list. The coordinate are correct there > though so this is probably unrelated (but i need to check if that does not > mean that the events are delayed of 300ms for that - likely a separate > issue). Could be that the SingleTapConfirmed code path is trigger by bug 942754 but this looks odd though since the target is not supposed to be a child APZC (my understanding of all this is still pretty raw).
Ok it seems like there is 2 issue here. One is that x and y of an event that is dispatched to an APZ controller can be wrong, the other is that the hit area of the APZ controller does not take into account elements that covers it partially and some events that should normally target the root APZC targets a child APZC.
(In reply to Vivien Nicolas (:vingtetun) (:21) (RTO - Review Time Off until 09/12/13) from comment #4) > Ok it seems like there is 2 issue here. One is that x and y of an event that > is dispatched to an APZ controller can be wrong, the other is that the hit > area of the APZ controller does not take into account elements that covers > it partially and some events that should normally target the root APZC > targets a child APZC. Rebuilding to see if the wrong x/y has been fixed since my build is a few days old. I'm pretty sure the hit test issue of AZPC is still here though.
The issue of the child APZC taking over the click is likely because of http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/APZCTreeManager.cpp#174 It seems like the visibility of the APZC is calculated without taking into account what's covered it. - So the fact that events wait for SingleTapConfirmed is likely bug 942754 (which probably add 300ms for now). - The wrong x/y is probably an issue somewhere in http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/APZCTreeManager.cpp#264 where the event coordinate are changed based on the targetted APZC (as far as I understand) - There is an other issue where the targetted APZC should not be the child but the root one as a mentionned at the beginning of this comment.
(In reply to Vivien Nicolas (:vingtetun) (:21) (RTO - Review Time Off until 09/12/13) from comment #6) > The issue of the child APZC taking over the click is likely because of > http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/ > APZCTreeManager.cpp#174 > > It seems like the visibility of the APZC is calculated without taking into > account what's covered it. > - So the fact that events wait for SingleTapConfirmed is likely bug 942754 > (which probably add 300ms for now). > > - The wrong x/y is probably an issue somewhere in > http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/ > APZCTreeManager.cpp#264 where the event coordinate are changed based on the > targetted APZC (as far as I understand) > > - There is an other issue where the targetted APZC should not be the child > but the root one as a mentionned at the beginning of this comment. It seems like the issue where the wrong APZC layer is targetted may be handle by bug 928833 which does not target 1.3. This is probably fine since this is not the biggest issue in this bug and at the end the events are sent to the window via nsIDOMWindowUtils if i'm correct. So this bug is probably about the wrong x/y for the list.
Even with an up-to-date Gecko I still have the wrong x/y issue. Maybe this is simply a duplicate then. Benoit, IIRC you were looking at the wrong dispatching of event target? Is this bug a dupe of something (bug 941215 is a bit confusing to me).
Flags: needinfo?(bgirard)
It's likely a dupe of bug 940706 (and half of the problem from 941215 is likely as well). You can try applying the patch from 940706 locally. I'm working on landing that one ASAP.
Flags: needinfo?(bgirard)
(In reply to Benoit Girard (:BenWa) from comment #9) > It's likely a dupe of bug 940706 (and half of the problem from 941215 is > likely as well). You can try applying the patch from 940706 locally. I'm > working on landing that one ASAP. You were right. The patch from bug 940706 solve the issue for me. Music works fine with it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Yay :)
You need to log in before you can comment on or make changes to this bug.