Bug 1817330 Comment 5 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 
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> Gecko never sends the INPUT_HANDLING_UNKNOWN, it's an uninitialzied state of InputResultDetail in Fenix.

I don't agree that this is an issue in Fenix.
Indeed I used our mapping of values above, so I'll refer to the values from `PanZoomController.java` now:

I tested on the today's featured article from wikipedia.com.
With logs added to `onTouchEventForDetailResult` I see that with the page scrolled to the middle a normal scroll down to get to the top of the page will have APZ send the following details:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```

 
---
But when I do a fast fling down and then up I see:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections ==  SCROLLABLE_FLAG_BOTTOM (4)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
folllowed by 
```
    inputResult == INPUT_RESULT_IGNORED (3)
    scrollDirections ==  SCROLLABLE_FLAG_NONE (0)
    overscrollDirections == OVERSCROLL_FLAG_NONE (0)
```
So you are right that because of the uninitialized state of InputResultDetail Fenix will not update the toolbar as expected.
But this is only happen because of the data GeckoView sends (or does not send) so in my opinion this is a APZ -> GeckoView bug.
According to the documentation for `INPUT_RESULT_IGNORED` - `Specifies that an input event was consumed by a PanZoomController internally and browsers should do nothing in response to the event`[3]

[1] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngineView.kt#173
[2] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/NestedGeckoView.kt#122-132
[3] https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#80-84
Revision 1 by
on 
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> Gecko never sends the INPUT_HANDLING_UNKNOWN, it's an uninitialzied state of InputResultDetail in Fenix.

I don't agree that this is an issue in Fenix.
Indeed I used our mapping of values above, so I'll refer to the values from `PanZoomController.java` now:

I tested on the today's featured article from wikipedia.com.
With logs added to `onTouchEventForDetailResult`[1] I see that with the page scrolled to the middle a normal scroll down to get to the top of the page will have APZ send the following details:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```

 
---
But when I do a fast fling down and then up I see:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections ==  SCROLLABLE_FLAG_BOTTOM (4)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
folllowed by 
```
    inputResult == INPUT_RESULT_IGNORED (3)
    scrollDirections ==  SCROLLABLE_FLAG_NONE (0)
    overscrollDirections == OVERSCROLL_FLAG_NONE (0)
```
So you are right that because of the uninitialized state of InputResultDetail Fenix will not update the toolbar as expected.
But this is only happen because of the data GeckoView sends (or does not send) so in my opinion this is a APZ -> GeckoView bug.
According to the documentation for `INPUT_RESULT_IGNORED` - `Specifies that an input event was consumed by a PanZoomController internally and browsers should do nothing in response to the event`[2]

 
---
Continuing from the above scenario (a fling up followed by a fling down to get the page scrolled to it's top the toolbar not leading to the toolbar to be expanded) the next immediate gesture which should trigger pull to refresh - a scroll down will not get do that because if looking at the response from `onTouchEventForDetailResult`[1] we get
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
based on which we will just now expand the toolbar but not also start pull to refresh since the page can still be scrolled to the top.


[1] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/NestedGeckoView.kt#122-132
[2] https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#80-84
Revision 2 by
on 
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> Gecko never sends the INPUT_HANDLING_UNKNOWN, it's an uninitialzied state of InputResultDetail in Fenix.

I don't agree that this is an issue in Fenix.
Indeed I used our mapping of values above, so I'll refer to the values from `PanZoomController.java` now:

I tested on the today's featured article from wikipedia.com.
With logs added to `onTouchEventForDetailResult`[1] I see that with the page scrolled to the middle a normal scroll down to get to the top of the page will have APZ send the following details:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```

 
---
But when I do a fast fling down and then up I see:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections ==  SCROLLABLE_FLAG_BOTTOM (4)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
folllowed by 
```
    inputResult == INPUT_RESULT_IGNORED (3)
    scrollDirections ==  SCROLLABLE_FLAG_NONE (0)
    overscrollDirections == OVERSCROLL_FLAG_NONE (0)
```
So you are right that because of the uninitialized state of InputResultDetail Fenix will not update the toolbar as expected.
But this is only happen because of the data GeckoView sends (or does not send) so in my opinion this is a APZ -> GeckoView bug.
According to the documentation for `INPUT_RESULT_IGNORED` - `Specifies that an input event was consumed by a PanZoomController internally and browsers should do nothing in response to the event`[2]

 
---
Continuing from the above scenario (a fling up followed by a fling down to get the page scrolled to it's top the toolbar not leading to the toolbar to be expanded) the next immediate gesture which should trigger pull to refresh - a scroll down will not get do that because if looking at the response from `onTouchEventForDetailResult`[1] we get
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
based on which we will just now expand the toolbar but not also start pull to refresh since GeckoView says that the page can still be scrolled to the top.


[1] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/NestedGeckoView.kt#122-132
[2] https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#80-84
Revision 3 by
on 
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> I believe this is an issue in Fenix. See bug 1724755.
> Gecko never sends the INPUT_HANDLING_UNKNOWN, it's an uninitialzied state of InputResultDetail in Fenix.

I don't agree that this is an issue in Fenix.
Indeed I used our mapping of values above, so I'll refer to the values from `PanZoomController.java` now:

I tested on the today's featured article from wikipedia.com.
With logs added to `onTouchEventForDetailResult`[1] I see that with the page scrolled to the middle a normal scroll down to get to the top of the page will have APZ send the following details:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```

 
---
But when I do a fast fling down and then up I see:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections ==  SCROLLABLE_FLAG_BOTTOM (4)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
folllowed by 
```
    inputResult == INPUT_RESULT_IGNORED (3)
    scrollDirections ==  SCROLLABLE_FLAG_NONE (0)
    overscrollDirections == OVERSCROLL_FLAG_NONE (0)
```
So you are right that because of the uninitialized state of InputResultDetail Fenix will not update the toolbar as expected.
But this is only happen because of the data GeckoView sends (or does not send) so in my opinion this is a APZ -> GeckoView bug.
According to the documentation for `INPUT_RESULT_IGNORED` - `Specifies that an input event was consumed by a PanZoomController internally and browsers should do nothing in response to the event`[2]

 
---
Continuing from the above scenario (a fling up followed by a fling down to get the page scrolled to it's top the toolbar not leading to the toolbar to be expanded) the next immediate gesture which should trigger pull to refresh - a scroll down will not get do that because if looking at the response from `onTouchEventForDetailResult`[1] we get
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
based on which we will just now expand the toolbar but not also start pull to refresh since GeckoView says that the page can still be scrolled to the top.


[1] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/NestedGeckoView.kt#122-132
[2] https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#80-84
Revision 4 by
on 
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> I believe this is an issue in Fenix. See bug 1724755.
> Gecko never sends the INPUT_HANDLING_UNKNOWN, it's an uninitialzied state of InputResultDetail in Fenix.

I don't agree that this is an issue in Fenix.
Indeed I used our mapping of values above, so I'll refer to the values from `PanZoomController.java` now:

I tested on the today's featured article from wikipedia.com.
With logs added to `onTouchEventForDetailResult`[1] I see that with the page scrolled to the middle a normal scroll down to get to the top of the page will have APZ send the following details:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```

 
---
But when I do a fast fling up and then down I see:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections ==  SCROLLABLE_FLAG_BOTTOM (4)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
folllowed by 
```
    inputResult == INPUT_RESULT_IGNORED (3)
    scrollDirections ==  SCROLLABLE_FLAG_NONE (0)
    overscrollDirections == OVERSCROLL_FLAG_NONE (0)
```
So you are right that because of the uninitialized state of InputResultDetail Fenix will not update the toolbar as expected.
But this is only happening because of the data GeckoView sends (or does not send) so in my opinion this is a APZ -> GeckoView bug.
According to the documentation for `INPUT_RESULT_IGNORED` - `Specifies that an input event was consumed by a PanZoomController internally and browsers should do nothing in response to the event`[2]

 
---
Continuing from the above scenario (a fling up followed by a fling down to get the page scrolled to it's top and the toolbar not getting expanded) the next immediate gesture which we'd expect to trigger pull to refresh - a scroll down will - not get do that because if looking at the response from `onTouchEventForDetailResult`[1] we get:
```
    inputResult == INPUT_RESULT_HANDLED (1)
    scrollDirections == SCROLLABLE_FLAG_TOP & SCROLLABLE_FLAG_BOTTOM (5)
    overscrollDirections == OVERSCROLL_FLAG_HORIZONTAL & OVERSCROLL_FLAG_VERTICAL (3)
```
based on which we will just now expand the toolbar but not also start pull to refresh since GeckoView says that the page can still be scrolled to the top.


[1] https://searchfox.org/mozilla-mobile/rev/93c7fc093c6fd5abe635740b4043d8b041025535/firefox-android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/NestedGeckoView.kt#122-132
[2] https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#80-84

Back to Bug 1817330 Comment 5