Closed Bug 1374682 Opened 7 years ago Closed 7 years ago

Allow having non-cancelable blocks in InputQueue

Categories

(Core :: Panning and Zooming, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

The InputBlockState and subclasses were originally designed to allow two classes of blocks: cancelable and non-cancelable. Right now all the blocks in existence derive from CancelableBlockState because they are cancelable. However we would like to add a non-cancelable block for keyboard inputs. So we should make sure the code can properly handle adding a subclass of InputBlockState that is not a subclass of CancelableBlockState.

This basically means QueuedInput should store a InputBlockState* instead of a CancelableBlockState* and propagate those changes outwards. Some helper functions might also need to be modified.

I have a WIP locally that I need to clean up.
Priority: -- → P3
Whiteboard: [gfx-noted]
Comment on attachment 8879603 [details]
Bug 1374682 - Clean up processing of non-cancelable input blocks in InputQueue.

https://reviewboard.mozilla.org/r/150938/#review156314

::: gfx/layers/apz/src/InputBlockState.h:68
(Diff revision 1)
> +    return nullptr;
> +  }
> +  virtual DragBlockState* AsDragBlock() {
> +    return nullptr;
> +  }
> +  virtual PanGestureBlockState *AsPanGestureBlock() {

Fix positioning of * while you're at it.

::: gfx/layers/apz/src/InputBlockState.cpp:229
(Diff revision 1)
>    }
>    return mContentResponded || mContentResponseTimerExpired;
>  }
>  
>  void
> -CancelableBlockState::DispatchEvent(const InputData& aEvent) const
> +InputBlockState::DispatchEvent(const InputData& aEvent) const

Can we move it to be next to the other InputBlockState method definitions?

::: gfx/layers/apz/src/InputQueue.cpp:582
(Diff revision 1)
>    APZThreadUtils::AssertOnControllerThread();
>  
>    INPQ_LOG("got a content response; block=%" PRIu64 "\n", aInputBlockId);
>    bool success = false;
> -  CancelableBlockState* block = FindBlockForId(aInputBlockId, nullptr);
> -  if (block) {
> +  InputData* firstInput = nullptr;
> +  InputBlockState* inputBlock = FindBlockForId(aInputBlockId, &firstInput);

Why are we passing in |firstInput| if we don't use it?
Attachment #8879603 - Flags: review?(botond) → review+
Comment on attachment 8879603 [details]
Bug 1374682 - Clean up processing of non-cancelable input blocks in InputQueue.

https://reviewboard.mozilla.org/r/150938/#review156314

> Fix positioning of * while you're at it.

Fixed

> Can we move it to be next to the other InputBlockState method definitions?

Done

> Why are we passing in |firstInput| if we don't use it?

Whoops, copy-paste error. Good catch! fixed also.
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4b6fe4dc69e3
Clean up processing of non-cancelable input blocks in InputQueue. r=botond
https://hg.mozilla.org/mozilla-central/rev/4b6fe4dc69e3
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: