Just to clarify, the way I was thinking about it is: - input events come in on input thread - input events get dispatched to APZ - APZ figures out which process the event is targeting - event gets sent to the appropriate process Therefore events destined for content processes would not go through the root process event dispatching mechanism and vice-versa. We would still need to keep all that machinery because there will still be some events that use it, and other platforms still need it (also the same code machinery is used on parent and child processes). So unfortunately there won't be much in terms of actual code deletion.
Component: Graphics → DOM: Events
nsWindow::DispatchTouchEVent->nsView->nsViewManager->nsPresShell->nsEventStateManager is the normal event dispatch, which Firefox and Mobile Firefox etc use, so deleting that any time soon isn't possible. Most of the touch events in b2g do already bypass the normal event dispatch machinery in the parent process, since the event just go from widget to TabParent.
(In reply to Olli Pettay [:smaug] from comment #2) > nsWindow::DispatchTouchEVent->nsView->nsViewManager->nsPresShell- > >nsEventStateManager > is the normal event dispatch, which Firefox and Mobile Firefox etc use, so > deleting > that any time soon isn't possible. > > Most of the touch events in b2g do already bypass the normal event dispatch > machinery in > the parent process, since the event just go from widget to TabParent. Doh :(. Yes, most of the touch events after APZ knows that a scrollable layer exists bypass the machinery. However, the touch starts always go through nsWindow::DispatchTouchEvent and can get consumed, which causes the current problems if we switch the order. Can we bypass that machinery in all cases, at least on platforms with APZ?
Created attachment 8473389 [details] [diff] [review] Ignore Content Timeouts I was thinking, I'm not sure if this will work, but it seems less risky than ignoring the gecko nsWindow::DispatchTouchEvent path. Currently, we have gonk->nsWindow->APZ -> Content. If the content doesn't respond with ContentReceivedTouch, we assume it is scrollable and start scrolling the content. How about we invert that and never assume content is scrollable in a timeout? So then we can have gonk->APZ->nsWindow->Content. If content never responds, we clear out the touch events in APZ. Thus, if nsWindow decides to consume the event, the event is never sent to content, solving the rocket bar issue. When the timeout executes, we clear out the touch. If a new touch start occurs before the timeout, we already clear out old touches, so no problem there. We have a few cases: 1) Normal case - Content responds in time and the timeout doesn't have to clear anything. Business as usual. 2) Touch is consumed by gecko - APZ processes it, sends a request to content. Content never sees the touch, so APZ::ContentTimeoutResponse fires and clears out the touch. 3) Touch is consumed by gecko, followed by another touch - APZ processes the touch, sends a request to content. Content never sees the touch, a new touch start occurs before ContentTimeoutResponse fires, we clear out the old touch event in APZ. 4) We create a tap - APZ creates a tap gesture, sees the touch start / move / ends, they are all consumed by gecko. Right now, we still send the gesture, we would have to change this to clear out gestures or only send out gestures AFTER AsyncPanZoomController::ContentReceivedTouch. This would solve the settings app problem, where we could scroll behind a menu pop up. Since gecko would consume this event, the ContentTimeoutResponse would fire and delete the touches and the gesture. I have a small test that just resets APZ on ContentTimeoutResponse. It fixes the rocketbar issue and normal scrolling at the moment works. Would this work? What was the original reason for assuming content could scroll if we timeout? Thanks!
Not sure if I understand correctly, but it sounds like you're suggesting that we don't scroll unless we hear back from stuff running on the main thread. That basically defeats the purpose of having APZ in the first place.
Resolving as the current plan moving forward is to get APZ to do proper hit testing on the parent process.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.