Bug 2031963 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
Okay, what I've found:

1) The `eApzAwareListeners;` code was not executed in between when APZ received the touch-start and when APZ received the first touch-move
2) During the above time span, 4 active touchmove event listeners were setup
3) in the first touch-move arrived at APZCTreeManager::ProcessTouchInput the hit results were:
```
(10, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 0, eVisibleToHitTest)
```
4) in the second touch-move event arrived at APZCTreeManager::ProcessTouchInput, I manually did a hit-testing by:
```
set $pt = (wr::WorldPoint*)malloc(8)                                                   
set ((float*)$pt)[0] = 634.0                             
set ((float*)$pt)[1] = 341.0                   
call $wr->HitTest(*$pt)
```
5) Then the results had eApzAwareListeners, so the active touchmove event listeners information had been arrived:
```
(10, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 0, eVisibleToHitTest | eApzAwareListeners) <= these scrollId:0 results might be irrelevant
( 0, eVisibleToHitTest) 
```

So from what I can tell is that this bug is a sort of performance issue on the main-thread.  If the up-to-date information can be arrived in APZ within a reasonable time span, the patches for bug 1839095 should have been fixed this bug too.

With that I am setting bug 1839095 in this bug's dependency list, also changing the diagnosis team from APZ to Performance.
Revision 1 by
on 
Okay, what I've found:

1) The `eApzAwareListeners;` code was not executed in between when APZ received the touch-start and when APZ received the first touch-move
2) During the above time span, 4 active touchmove event listeners were setup
3) in the first touch-move arrived at APZCTreeManager::ProcessTouchInput the hit results were:
```
(10, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 0, eVisibleToHitTest)
```
4) when the second touch-move event arrived at APZCTreeManager::ProcessTouchInput, I manually did a hit-testing by:
```
set $pt = (wr::WorldPoint*)malloc(8)                                                   
set ((float*)$pt)[0] = 634.0                             
set ((float*)$pt)[1] = 341.0                   
call $wr->HitTest(*$pt)
```
5) Then the results had eApzAwareListeners, so the active touchmove event listeners information had been arrived:
```
(10, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 0, eVisibleToHitTest | eApzAwareListeners) <= these scrollId:0 results might be irrelevant
( 0, eVisibleToHitTest) 
```

So from what I can tell is that this bug is a sort of performance issue on the main-thread.  If the up-to-date information can be arrived in APZ within a reasonable time span, the patches for bug 1839095 should have been fixed this bug too.

With that I am setting bug 1839095 in this bug's dependency list, also changing the diagnosis team from APZ to Performance.
Revision 2 by
on 
Okay, what I've found:

1) The `eApzAwareListeners;` code was not executed in between when APZ received the touch-start and when APZ received the first touch-move
2) During the above time span, 4 active touchmove event listeners were setup
3) in the first touch-move arrived at APZCTreeManager::ProcessTouchInput the hit results were:
```
(10, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 0, eVisibleToHitTest)
```
4) when the second touch-move event arrived at APZCTreeManager::ProcessTouchInput, I manually did a hit-testing by:
```
set $pt = (wr::WorldPoint*)malloc(8)                                                   
set ((float*)$pt)[0] = 634.0                             
set ((float*)$pt)[1] = 341.0                   
call $wr->HitTest(*$pt)
```
5) Then the results had eApzAwareListeners, so the active touchmove event listeners information had arrived:
```
(10, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 0, eVisibleToHitTest | eApzAwareListeners) <= these scrollId:0 results might be irrelevant
( 0, eVisibleToHitTest) 
```

So from what I can tell is that this bug is a sort of performance issue on the main-thread.  If the up-to-date information can be arrived in APZ within a reasonable time span, the patches for bug 1839095 should have been fixed this bug too.

With that I am setting bug 1839095 in this bug's dependency list, also changing the diagnosis team from APZ to Performance.
Revision 3 by
on 
Okay, what I've found:

1) The `eApzAwareListeners;` code was not executed in between when APZ received the touch-start and when APZ received the first touch-move
2) During the above time span, 4 active touchmove event listeners were setup
3) when the first touch-move arrived at APZCTreeManager::ProcessTouchInput the hit results were:
```
(10, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 9, eVisibleToHitTest)                                                                                  
( 0, eVisibleToHitTest)
```
4) when the second touch-move event arrived at APZCTreeManager::ProcessTouchInput, I manually did a hit-testing by:
```
set $pt = (wr::WorldPoint*)malloc(8)                                                   
set ((float*)$pt)[0] = 634.0                             
set ((float*)$pt)[1] = 341.0                   
call $wr->HitTest(*$pt)
```
5) Then the results had eApzAwareListeners, so the active touchmove event listeners information had arrived:
```
(10, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 9, eVisibleToHitTest | eApzAwareListeners)
( 0, eVisibleToHitTest | eApzAwareListeners) <= these scrollId:0 results might be irrelevant
( 0, eVisibleToHitTest) 
```

So from what I can tell is that this bug is a sort of performance issue on the main-thread.  If the up-to-date information can be arrived in APZ within a reasonable time span, the patches for bug 1839095 should have been fixed this bug too.

With that I am setting bug 1839095 in this bug's dependency list, also changing the diagnosis team from APZ to Performance.

Back to Bug 2031963 Comment 11