Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2010133003:
Add ScrollManager class (Closed)
|
Created:
4 years, 6 months ago by Navid Zolghadr Modified:
4 years, 6 months ago CC:
chromium-reviews, blink-reviews, dtapuska+blinkwatch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdd ScrollManager class
Extract scrolling and resizing related logic
from EventHandler and put it in a dedicated
class.
BUG=615079
Committed: https://crrev.com/c517903e4714fac5e85e9e38fb7316d5df36cc46
Cr-Commit-Position: refs/heads/master@{#397485}
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #
Total comments: 23
Patch Set 4 : Applying comments #Patch Set 5 : #
Total comments: 12
Patch Set 6 : Adding TODOs #
Messages
Total messages: 18 (4 generated)
nzolghadr@chromium.org changed reviewers: + dtapuska@chromium.org, mustaq@chromium.org
https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:522: if (!layoutObject->isBox()) This seems like something that should be delegated to the ScrollManager. ie; I'd try to remove the API autoScrollController() on the ScrollManager class as that indicates you have then encapsulation correct. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:756: // here because of an onLoad event, in which case the final layout hasn't been performed yet. It would seem to me bubbling scroll would just get delegated as well. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:3490: ScrollDirection direction = event->shiftKey() ? ScrollBlockDirectionBackward : ScrollBlockDirectionForward; I wonder if defaultSpaceEventHandler and defaultWheelEventHandler (which I need to remove). Should be in the ScrollManager.cpp. Then we can remove logicalScroll and physicalScroll from the ScrollManager public interface. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:450: AutoscrollController* controller = m_scrollManager.autoscrollController(); Why can't this just be a call to m_scrollManager.stopAutoScroll() instead of loading the AutoScrollController? https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.h (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.h:411: Member<Node> m_capturingMouseEventsNode; Can we remove HandleGestureScrollUpdate/End/Begin from this class? https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.cpp (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.cpp:617: const PlatformGestureEvent& gestureEvent = targetedEvent.event(); do you need to put this on the stack? Should be able to just pass it in. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.h (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:35: public: Probably want to disallow copy and assign on this class too.. WTF_MAKE_NONCOPYABLE(ScrollManager); ? https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:81: bool logicalScroll(ScrollDirection, ScrollGranularity, Node* startNode = nullptr, Node* mousePressNode = nullptr); Remove optional args. All your call sites have 4 args. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:88: WebInputEventResult handleGestureScrollUpdate(const PlatformGestureEvent&); Why are these public? I think they can be made private because the signatures in EventHandler aren't necessary. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:100: void clearResizeScrollableArea(bool); You need some declaration as to what this bool is...
I have applied some of the comments as much as I thought it was obvious. But I had a few questions for some of them inline. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:522: if (!layoutObject->isBox()) On 2016/05/27 14:12:23, dtapuska wrote: > This seems like something that should be delegated to the ScrollManager. > > ie; I'd try to remove the API autoScrollController() on the ScrollManager class > as that indicates you have then encapsulation correct. This seems a little tricky to remove autoScrollController altogether now. It's been used in a few places and I need to add all those as APIs. Is that what you mean? https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:756: // here because of an onLoad event, in which case the final layout hasn't been performed yet. On 2016/05/27 14:12:23, dtapuska wrote: > It would seem to me bubbling scroll would just get delegated as well. Done. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:3490: ScrollDirection direction = event->shiftKey() ? ScrollBlockDirectionBackward : ScrollBlockDirectionForward; On 2016/05/27 14:12:23, dtapuska wrote: > I wonder if defaultSpaceEventHandler and defaultWheelEventHandler (which I need > to remove). > > Should be in the ScrollManager.cpp. Then we can remove logicalScroll and > physicalScroll from the ScrollManager public interface. > > > I wanted to move DefaultSpaceEventHandler to another class KeyboardEventManager and that class will call the scrolling functions from ScrollManager class. Is that okay? https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:450: AutoscrollController* controller = m_scrollManager.autoscrollController(); On 2016/05/27 14:12:23, dtapuska wrote: > Why can't this just be a call to m_scrollManager.stopAutoScroll() instead of > loading the AutoScrollController? stopAutoScroll is used in other places without this autoscrollInProgress check. So I was not sure if that is okay to do that. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.h (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.h:411: Member<Node> m_capturingMouseEventsNode; On 2016/05/27 14:12:23, dtapuska wrote: > Can we remove HandleGestureScrollUpdate/End/Begin from this class? Done with Update and Begin. But End one is being used outside. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.cpp (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.cpp:617: const PlatformGestureEvent& gestureEvent = targetedEvent.event(); On 2016/05/27 14:12:23, dtapuska wrote: > do you need to put this on the stack? Should be able to just pass it in. Yup. You are right. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.h (right): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:35: public: On 2016/05/27 14:12:23, dtapuska wrote: > Probably want to disallow copy and assign on this class too.. > > WTF_MAKE_NONCOPYABLE(ScrollManager); ? Done. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:81: bool logicalScroll(ScrollDirection, ScrollGranularity, Node* startNode = nullptr, Node* mousePressNode = nullptr); On 2016/05/27 14:12:23, dtapuska wrote: > Remove optional args. All your call sites have 4 args. Done. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:88: WebInputEventResult handleGestureScrollUpdate(const PlatformGestureEvent&); On 2016/05/27 14:12:23, dtapuska wrote: > Why are these public? I think they can be made private because the signatures in > EventHandler aren't necessary. Done. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:100: void clearResizeScrollableArea(bool); On 2016/05/27 14:12:23, dtapuska wrote: > You need some declaration as to what this bool is... Done.
https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:466: void EventHandler::startPanScrolling(LayoutObject* layoutObject) I think it's fine to move startPanScrolling() to scrollManager, even outside #if. This will give us the chance to include panScrolling in non-Win cases if needed. Keep the wrapper here plus the click invalidation, inside #if, rename to startPanScrollingInvalidatingClick. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:2003: WebInputEventResult EventHandler::handleGestureScrollEnd(const PlatformGestureEvent& gestureEvent) There seems to be many "op-op" wrappers to a corresponding scollManager functions. This is an indication that adding a public EventHandler::scrollMamanger() (return m_scrollManager} may be a better idea.
https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:2003: WebInputEventResult EventHandler::handleGestureScrollEnd(const PlatformGestureEvent& gestureEvent) On 2016/05/31 16:04:11, mustaq wrote: > There seems to be many "op-op" wrappers to a corresponding scollManager > functions. This is an indication that adding a public > EventHandler::scrollMamanger() (return m_scrollManager} may be a better idea. I thought that too. But I wanted to have that sort of APIs more clear with this op-op way in EventHandler. This way it is clear that these APIs from EventHandler are being called in different places in the code. In other words no class accesses the *Manager class APIs directly and outside of this folder (or outside of its frame). This way it is more clear what APIs of a frame are exposed to other frames/classes. Is that reasonable?
nzolghadr@chromium.org changed reviewers: + bokan@chromium.org
It's a little hard to tell due to the amount of code, are there any significant changes here or is it strictly just code being moved? The overall movement and new manager class look fine to me but I didn't look at all the details. Let me know if there's something I should look more closely at. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:522: if (!layoutObject->isBox()) On 2016/05/30 20:15:46, Navid Zolghadr wrote: > On 2016/05/27 14:12:23, dtapuska wrote: > > This seems like something that should be delegated to the ScrollManager. > > > > ie; I'd try to remove the API autoScrollController() on the ScrollManager > class > > as that indicates you have then encapsulation correct. > > This seems a little tricky to remove autoScrollController altogether now. It's > been used in a few places and I need to add all those as APIs. Is that what you > mean? I'd prefer if we kept this patch as simple and mechanical as possible as it's moving a lot of code. We can do untangling like this in a follow up. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:3490: ScrollDirection direction = event->shiftKey() ? ScrollBlockDirectionBackward : ScrollBlockDirectionForward; On 2016/05/30 20:15:46, Navid Zolghadr wrote: > On 2016/05/27 14:12:23, dtapuska wrote: > > I wonder if defaultSpaceEventHandler and defaultWheelEventHandler (which I > need > > to remove). > > > > Should be in the ScrollManager.cpp. Then we can remove logicalScroll and > > physicalScroll from the ScrollManager public interface. > > > > > > > > I wanted to move DefaultSpaceEventHandler to another class KeyboardEventManager > and that class will call the scrolling functions from ScrollManager class. Is > that okay? This plan sgtm. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:2003: WebInputEventResult EventHandler::handleGestureScrollEnd(const PlatformGestureEvent& gestureEvent) On 2016/05/31 16:11:16, Navid Zolghadr wrote: > On 2016/05/31 16:04:11, mustaq wrote: > > There seems to be many "op-op" wrappers to a corresponding scollManager > > functions. This is an indication that adding a public > > EventHandler::scrollMamanger() (return m_scrollManager} may be a better idea. > > I thought that too. But I wanted to have that sort of APIs more clear with this > op-op way in EventHandler. This way it is clear that these APIs from > EventHandler are being called in different places in the code. In other words no > class accesses the *Manager class APIs directly and outside of this folder (or > outside of its frame). This way it is more clear what APIs of a frame are > exposed to other frames/classes. Is that reasonable? I think it's fine to make EventHandler the "interface" and let it delegate to the various managers. At the least, this is a good start to breaking everything apart for more cleanup down the line. Once we've broken up EventHandler, maybe we'll decide that different managers should have different visibility to the higher levels but I think that's premature for now so I'm fine with this as-is. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.cpp:308: WebInputEventResult ScrollManager::handleGestureScrollBegin(const PlatformGestureEvent& gestureEvent) To me, this and (related methods) seems like it belongs in EventHandler or some new GestureHandler class which should unpack and interpret the GestureScroll event. Once it's decided how much and in what way to scroll, it should pass that information to the ScrollManager to actually execute the scroll. That said, I'm happy to keep this for now to facilitate breaking up EventHandler. Once we untangle the mess it should be easier to tell where the lines of separation should be. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.h (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:33: class CORE_EXPORT ScrollManager { Please add a class-level comment describing this class' purpose, how it fits in the event handling system, and what kinds of data/methods belong in here.
https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:2003: WebInputEventResult EventHandler::handleGestureScrollEnd(const PlatformGestureEvent& gestureEvent) On 2016/05/31 19:39:13, bokan wrote: > On 2016/05/31 16:11:16, Navid Zolghadr wrote: > > On 2016/05/31 16:04:11, mustaq wrote: > > > There seems to be many "op-op" wrappers to a corresponding scollManager > > > functions. This is an indication that adding a public > > > EventHandler::scrollMamanger() (return m_scrollManager} may be a better > idea. > > > > I thought that too. But I wanted to have that sort of APIs more clear with > this > > op-op way in EventHandler. This way it is clear that these APIs from > > EventHandler are being called in different places in the code. In other words > no > > class accesses the *Manager class APIs directly and outside of this folder (or > > outside of its frame). This way it is more clear what APIs of a frame are > > exposed to other frames/classes. Is that reasonable? > > I think it's fine to make EventHandler the "interface" and let it delegate to > the various managers. At the least, this is a good start to breaking everything > apart for more cleanup down the line. Once we've broken up EventHandler, maybe > we'll decide that different managers should have different visibility to the > higher levels but I think that's premature for now so I'm fine with this as-is. +1 on deferring the visibility of the sub-units, but I would ask for a TODO so that it doesn't fall through the cracks. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.cpp:308: WebInputEventResult ScrollManager::handleGestureScrollBegin(const PlatformGestureEvent& gestureEvent) On 2016/05/31 19:39:13, bokan wrote: > To me, this and (related methods) seems like it belongs in EventHandler or some > new GestureHandler class which should unpack and interpret the GestureScroll > event. Once it's decided how much and in what way to scroll, it should pass that > information to the ScrollManager to actually execute the scroll. > > That said, I'm happy to keep this for now to facilitate breaking up > EventHandler. Once we untangle the mess it should be easier to tell where the > lines of separation should be. Again, may be a TODO in the class-level comment in .h?
ptal. I believe I applied all the comments and I hope that I didn't miss any as they were in different patches. Let me know if you see anything is missing. As Bokan suggested I kept this change mostly moving code around instead of changing the implementation of some of the functions. https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (left): https://codereview.chromium.org/2010133003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:522: if (!layoutObject->isBox()) On 2016/05/31 19:39:13, bokan wrote: > On 2016/05/30 20:15:46, Navid Zolghadr wrote: > > On 2016/05/27 14:12:23, dtapuska wrote: > > > This seems like something that should be delegated to the ScrollManager. > > > > > > ie; I'd try to remove the API autoScrollController() on the ScrollManager > > class > > > as that indicates you have then encapsulation correct. > > > > This seems a little tricky to remove autoScrollController altogether now. It's > > been used in a few places and I need to add all those as APIs. Is that what > you > > mean? > > I'd prefer if we kept this patch as simple and mechanical as possible as it's > moving a lot of code. We can do untangling like this in a follow up. Okay then. I'll leave this function as is. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/EventHandler.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:466: void EventHandler::startPanScrolling(LayoutObject* layoutObject) On 2016/05/31 16:04:11, mustaq wrote: > I think it's fine to move startPanScrolling() to scrollManager, even outside > #if. This will give us the chance to include panScrolling in non-Win cases if > needed. Keep the wrapper here plus the click invalidation, inside #if, rename to > startPanScrollingInvalidatingClick. As Bokan suggested let's keep this function here as is and leave this CL for only moving the code. I'll change this function in the later cleanups. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/EventHandler.cpp:2003: WebInputEventResult EventHandler::handleGestureScrollEnd(const PlatformGestureEvent& gestureEvent) On 2016/05/31 20:20:10, mustaq wrote: > On 2016/05/31 19:39:13, bokan wrote: > > On 2016/05/31 16:11:16, Navid Zolghadr wrote: > > > On 2016/05/31 16:04:11, mustaq wrote: > > > > There seems to be many "op-op" wrappers to a corresponding scollManager > > > > functions. This is an indication that adding a public > > > > EventHandler::scrollMamanger() (return m_scrollManager} may be a better > > idea. > > > > > > I thought that too. But I wanted to have that sort of APIs more clear with > > this > > > op-op way in EventHandler. This way it is clear that these APIs from > > > EventHandler are being called in different places in the code. In other > words > > no > > > class accesses the *Manager class APIs directly and outside of this folder > (or > > > outside of its frame). This way it is more clear what APIs of a frame are > > > exposed to other frames/classes. Is that reasonable? > > > > I think it's fine to make EventHandler the "interface" and let it delegate to > > the various managers. At the least, this is a good start to breaking > everything > > apart for more cleanup down the line. Once we've broken up EventHandler, maybe > > we'll decide that different managers should have different visibility to the > > higher levels but I think that's premature for now so I'm fine with this > as-is. > > +1 on deferring the visibility of the sub-units, but I would ask for a TODO so > that it doesn't fall through the cracks. Done. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.cpp (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.cpp:308: WebInputEventResult ScrollManager::handleGestureScrollBegin(const PlatformGestureEvent& gestureEvent) On 2016/05/31 20:20:10, mustaq wrote: > On 2016/05/31 19:39:13, bokan wrote: > > To me, this and (related methods) seems like it belongs in EventHandler or > some > > new GestureHandler class which should unpack and interpret the GestureScroll > > event. Once it's decided how much and in what way to scroll, it should pass > that > > information to the ScrollManager to actually execute the scroll. > > > > That said, I'm happy to keep this for now to facilitate breaking up > > EventHandler. Once we untangle the mess it should be easier to tell where the > > lines of separation should be. > > Again, may be a TODO in the class-level comment in .h? I was on the fence on whether to put the scroll gestures in ScrollManager and touch gestures in TouchManager or put all gestures in one single GestureManager class. Since you are in favor of putting them all in one as well I'll go with that then. I have filed an issue and added the TODO in .h file. https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/input/ScrollManager.h (right): https://codereview.chromium.org/2010133003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/input/ScrollManager.h:33: class CORE_EXPORT ScrollManager { On 2016/05/31 19:39:14, bokan wrote: > Please add a class-level comment describing this class' purpose, how it fits in > the event handling system, and what kinds of data/methods belong in here. Done.
lgtm
The CQ bit was checked by nzolghadr@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/2010133003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/2010133003/100001
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== Add ScrollManager class Extract scrolling and resizing related logic from EventHandler and put it in a dedicated class. BUG=615079 ========== to ========== Add ScrollManager class Extract scrolling and resizing related logic from EventHandler and put it in a dedicated class. BUG=615079 Committed: https://crrev.com/c517903e4714fac5e85e9e38fb7316d5df36cc46 Cr-Commit-Position: refs/heads/master@{#397485} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/c517903e4714fac5e85e9e38fb7316d5df36cc46 Cr-Commit-Position: refs/heads/master@{#397485} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
