search

chromiumembedded / cef

Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.
https://bitbucket.org/chromiumembedded/cef/
Other
3.33k stars 466 forks source link

OSR PDF Scrolling with MouseWheel/Keyboard not working #2078

Closed magreenblatt closed 7 years ago

magreenblatt commented 7 years ago

Original report by amaitland (Bitbucket: amaitland, GitHub: amaitland).

What steps will reproduce the problem?

Open cefclient --multi-threaded-message-loop --off-screen-rendering-enabled Navigate to a PDF with Multiple pages e.g. http://www.msy.com.au/Parts/PARTS.pdf

What is the expected output? What do you see instead?

PDF should scroll with mouse wheel or keyboard arrow keys, instead it just flickers. Using the scrollbar works as expected.

What version of the product are you using? On what operating system?

Tested with cef_binary_3.2883.1545.gd685d27_windows32_client on Windows 10 x64 14393.693 (downloaded from spotify build server)

Does the problem reproduce with the cefclient or cefsimple sample application at the same version? How about with a newer or older version?

Yes, reproduces in cefclient. I have yet to try a newer branch.

Does the problem reproduce with Google Chrome at the same version? How about with a newer or older version?

PDF's work correctly in Chrome

magreenblatt commented 7 years ago

Testing cefclient.exe --off-screen-rendering-enabled --url=http://tests/pdf.pdf with 2924 branch on Windows 10 the PDF scrolls incorrectly with touchpad as well.

magreenblatt commented 7 years ago

Original comment by Zheng Luo (Bitbucket: htfy96, GitHub: htfy96).

Confirmed on cef_binary_3.2883.1553.g80bd606_windows64 with cefclients.exe --off-screen-rendering-enabled --url=http://cgi.di.uoa.gr/~passas/ATM_Workshop_CR.pdf. Scrollbar works well but once I scroll mousewheel, the webpage goes black. bug-scroll.png

magreenblatt commented 7 years ago

Original comment by M S (Bitbucket: barbeque, GitHub: barbeque).

Can confirm that this is still happening on 32-bit Windows 3.2987.1601-gf035232 (from spotify builds, Chromium version 57.0.2987.133) with:

cefclient --multi-threaded-message-loop --off-screen-rendering-enabled --url=test.pdf

The screen doesn't go blank, but the browser view does not appear to update properly ("stuck" until a different mouse event happens?) Scrollbar works well.

magreenblatt commented 7 years ago

Original comment by Zheng Luo (Bitbucket: htfy96, GitHub: htfy96).

In 3.2987.1601.gf035232 black screen disappears, but when I scroll mousewheel in any direction, the PDF just scrolls to the end immediately.

magreenblatt commented 7 years ago

Original comment by Weyn Ong (Bitbucket: wongqsr).

I'm seeing glitches with mouse-wheel scrolling even in HTML pages. When running cefclient.exe and going to any Google results page (for example), scrolling via the mouse wheel is glitchy (jumps around) and doesn't scroll the page all the way to the end.

This occurs with 64-bit Windows 3.3029.1611 from spotify builds, Chromium 58.0.3029.81.

cefclient.exe --multi-threaded-message-loop --off-screen-rendering-enabled

OS: Windows 7 64-bit

Is anyone else experiencing this with HTML pages?

magreenblatt commented 7 years ago

Original comment by nexusseven (Bitbucket: nexusseven, GitHub: nexusseven).

@wongqsr - yes I'm seeing the same thing too. As far as I can tell, it's been broken for the last few releases, and is preventing me upgrading my app to the latest versions.

magreenblatt commented 7 years ago

Original comment by Alexey Makarov (Bitbucket: makap, GitHub: makap).

Hi! Additionail info. On 64-bit Windows10 I'm start cefclient32 ( cef_binary_3.2987.1601.gf035232_windows32_client) from spotify builds as cefclient.exe --multi-threaded-message-loop --off-screen-rendering-enabled , then navigate to http://cgi.di.uoa.gr/~passas/ATM_Workshop_CR.pdf and mouse scroll down and once again go back to the previous page... Cefclient crashed. Working cefclient without options --off-screen-rendering-enabled is Ok! P.S. Navigating to a previous page or to a new address after downloading a PDF file results in the application crashing.

Maybe New Bug? @magreenblatt

cef_binary_3.3029.1612.gd81997a_windows32_client is worked fine.

magreenblatt commented 7 years ago

@makap Likely already fixed since it works fine with current versions.

magreenblatt commented 7 years ago

Original comment by Zheng Luo (Bitbucket: htfy96, GitHub: htfy96).

In 3.3029.1613.g22354a9_windows64 crash disappears, though scroll is still broken: no action when scrolling mousewheel with --off-screen-rendering-enabled in cefclient.exe

magreenblatt commented 7 years ago

Original comment by Victor Jurado (Bitbucket: victor_jurado).

Just debugging on a 2924 (but looks like on 3029 stills the same)

Issue looks like appear on

#!c++

void RenderWidgetHostViewGuest::OnHandleInputEvent(
    RenderWidgetHostImpl* embedder,
    int browser_plugin_instance_id,
    const blink::WebInputEvent* event) {
  // WebMouseWheelEvents go into a queue, and may not be forwarded to the
  // renderer until after this method goes out of scope. Therefore we need to
  // explicitly remove the additional device scale factor from the coordinates
  // before allowing the event to be queued.
  if (IsUseZoomForDSFEnabled() &&
      event->type == blink::WebInputEvent::MouseWheel) {
    blink::WebMouseWheelEvent rescaled_event =
        *static_cast<const blink::WebMouseWheelEvent*>(event);
    rescaled_event.x /= current_device_scale_factor();
    rescaled_event.y /= current_device_scale_factor();
    rescaled_event.deltaX /= current_device_scale_factor();
    rescaled_event.deltaY /= current_device_scale_factor();
    rescaled_event.wheelTicksX /= current_device_scale_factor();
    rescaled_event.wheelTicksY /= current_device_scale_factor();
    ui::LatencyInfo latency_info(ui::SourceEventType::WHEEL);
    host_->ForwardWheelEventWithLatencyInfo(rescaled_event, latency_info);
    return;
  }

When the event is being forwarded. After that, wheel event is on nan/inf who causes the pdf view to calculate an incorrect scroll offset and eventually crash. So i suspect device scale factor ..

Confirmed:

render_widget_host_view_base.cc set in the constructor by CEF patch current_device_scalefactor(0), and never got changed producing that bad transformation for wheel event in that case.

Tried to set to 1.0 as default in the constructor as a workaround and looks like everything is going fine. Mouse wheel is back.

On windowed mode, the function "bool RenderWidgetHostViewBase::HasDisplayPropertyChanged(gfx::NativeView view)" is called, so, scale factor is set properly and everything is working fine.

Marshall. I don't know too much about the internals, sure you will find a fix for this but i hope this gives you a clue. Guess that thing got broken for OSR because Aura changes.

Cheers.

magreenblatt commented 7 years ago

Using the 3071 branch on Windows I'm getting the following renderer process assertion when scrolling the OSR PDF view with the touchpad. |event.GetType()| is kGestureScrollBegin, |gesture_event.resending_plugin_id| is -1 and |browser_plugin_instanceid| is 3.

[0622/130051.233:FATAL:browser_plugin.cc(464)] Check failed: blink::WebInputEvent::kGestureTapDown == event.GetType() || gesture_event.resending_plugin_id == browser_plugin_instance_id_. 

    libcef.dll!base::debug::BreakDebugger() Line 21 C++
    libcef.dll!logging::LogMessage::~LogMessage() Line 762  C++
>   libcef.dll!content::BrowserPlugin::HandleInputEvent(const blink::WebInputEvent & event, blink::WebCursorInfo & cursor_info) Line 468    C++
    libcef.dll!blink::WebPluginContainerImpl::HandleGestureEvent(blink::GestureEvent * event) Line 890  C++
    libcef.dll!blink::WebPluginContainerImpl::HandleEvent(blink::Event * event) Line 220    C++
    libcef.dll!blink::HTMLPlugInElement::DefaultEventHandler(blink::Event * event) Line 457 C++
    libcef.dll!blink::EventDispatcher::DispatchEventPostProcess(blink::EventDispatchHandlingState * pre_dispatch_event_handler_result) Line 288 C++
    libcef.dll!blink::EventDispatcher::Dispatch() Line 163  C++
    libcef.dll!blink::EventDispatchMediator::DispatchEvent(blink::EventDispatcher & dispatcher) Line 52 C++
    libcef.dll!blink::EventDispatcher::DispatchEvent(blink::Node & node, blink::EventDispatchMediator * mediator) Line 59   C++
    libcef.dll!blink::Node::DispatchEventInternal(blink::Event * event) Line 2113   C++
    libcef.dll!blink::EventTarget::DispatchEvent(blink::Event * event) Line 474 C++
    libcef.dll!blink::ScrollManager::HandleGestureScrollEvent(const blink::WebGestureEvent & gesture_event) Line 518    C++
    libcef.dll!blink::EventHandler::HandleGestureScrollEvent(const blink::WebGestureEvent & gesture_event) Line 1375    C++
    libcef.dll!blink::WebViewImpl::HandleGestureEvent(const blink::WebGestureEvent & event) Line 763    C++
    libcef.dll!blink::PageWidgetDelegate::HandleInputEvent(blink::PageWidgetEventHandler & handler, const blink::WebCoalescedInputEvent & coalesced_event, blink::LocalFrame * root) Line 201   C++
    libcef.dll!blink::WebViewImpl::HandleInputEvent(const blink::WebCoalescedInputEvent & coalesced_event) Line 2252    C++
    libcef.dll!blink::WebViewFrameWidget::HandleInputEvent(const blink::WebCoalescedInputEvent & event) Line 94 C++
    libcef.dll!content::RenderWidgetInputHandler::HandleInputEvent(const blink::WebCoalescedInputEvent & coalesced_event, const ui::LatencyInfo & latency_info, content::InputEventDispatchType dispatch_type) Line 315 C++
    libcef.dll!content::RenderWidget::OnHandleInputEvent(const blink::WebInputEvent * input_event, const std::vector<blink::WebInputEvent const *,std::allocator<blink::WebInputEvent const *> > & coalesced_events, const ui::LatencyInfo & latency_info, content::InputEventDispatchType dispatch_type) Line 816  C++

This or a similar crash also occurs with 3.3029.1613.g22354a9 but not 3.2987.1601.gf035232.

magreenblatt commented 7 years ago

@victor_jurado Thanks for the analysis. That helped.

magreenblatt commented 7 years ago

After fixing the above crash by routing MouseWheel events via the guest RWHV in CefRenderWidgetHostViewOSR::SendMouseWheelEvent the MouseWheel handling is now bailing out in BrowserPlugin::HandleInputEvent due to the following code:

  // With direct event routing turned on, BrowserPlugin should almost never
  // see wheel events any more. The two exceptions are (1) scroll bubbling, and
  // (2) synthetic mouse wheels generated by touchpad GesturePinch events on
  // Mac, which always go to the mainframe and thus may hit BrowserPlugin if
  // it's in a top-level embedder. In both cases we should indicate the event
  // as not handled (for GesturePinch on Mac, indicating the event has been
  // handled leads to touchpad pinch not working).
  if (event.GetType() == blink::WebInputEvent::kMouseWheel)
    return blink::WebInputEventResult::kNotHandled;

I've posted a question about this to the input-dev mailing list: https://groups.google.com/a/chromium.org/d/msg/input-dev/_ruiZXhiy-c/oTybbbabAQAJ

magreenblatt commented 7 years ago

Fixed in master revision cb0dfcc (bb), 3112 branch revision 7afb6c6 (bb) and 3071 branch revision 408afd1 (bb).

magreenblatt commented 7 years ago

Re-opening. There appears to be an issue with keyboard focus causing mouse events to stop working in the PDF view.

magreenblatt commented 7 years ago

The keyboard issue is due to RWHVGuest having an incorrect device_scalefactor. The ScopedInputScaleDisabler used by RenderWidgetHostViewGuest::OnHandleInputEvent when receiving keyboard events is calling InputRouterImpl::SetDeviceScaleFactor with this incorrect value from its destructor and as a result the event's widget position is calculated incorrectly in InputRouterImpl::OfferToRenderer from that point onward.

magreenblatt commented 7 years ago

Fixed in master revision 75acd20 (bb), 3112 branch revision a906bdd (bb) and 3071 branch revision f54b5cd (bb).

magreenblatt commented 7 years ago
magreenblatt commented 7 years ago
magreenblatt commented 7 years ago
magreenblatt commented 7 years ago