This would allow a plugin to implement scrollbars in its region, for example.
Created attachment 50270 [details] Proposed patch I don't like how I can't set m_haveMouseCapture to false in mouseCaptureLost(), any suggestions?
Attachment 50270 [details] did not build on chromium: Build output: http://webkit-commit-queue.appspot.com/results/453001
Created attachment 50276 [details] Added missing file
What if WebWidget::mouseCaptureLost() is called? See the callsite in chrome/renderer/render_widget.cc.
Right, that's my worry, that the window loses mouse capture without a right mouse button up event. Is it possible though?
Created attachment 50350 [details] Updated patch Per Darin's advice, reversed the order that the browser sends the events (http://codereview.chromium.org/743003). This makes this change cleaner.
Comment on attachment 50350 [details] Updated patch > Index: WebKit/chromium/src/WebViewImpl.cpp ... > + if (m_haveMouseCapture && WebInputEvent::isMouseEventType(inputEvent.type)) { > + Node* node = focusedWebCoreNode(); > + if (node && node->renderer() && node->renderer()->isEmbeddedObject()) { > + AtomicString eventType; > + switch (inputEvent.type) { nit: indentation of AtomicString is off. > void WebViewImpl::mouseCaptureLost() > { > + m_haveMouseCapture = false; > } We may eventually wish to pass this event along to the plugin. Are there any compatibility concerns with enabling this patch for ordinary plugins?
My hunch is that there shouldn't be any issue with passing this to NPAPI plugins. Basic testing with Flash hasn't shown any problems, but pushing this out will tell us conclusively.
Committed r55758
(In reply to comment #8) > My hunch is that there shouldn't be any issue with passing this to NPAPI > plugins. Basic testing with Flash hasn't shown any problems, but pushing this > out will tell us conclusively. OK, sounds good.