Re: Issue 114517 in chromium: Setting window title resets cursor

[chro...@googlecode.com]

Comment #13 on issue 114517 by rn...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

This appears to be a WebKit bug. I can reproduce the same issue on WebKit.

[chro...@googlecode.com]

Updates:
Labels: WebKit-ID-78858

Comment #16 on issue 114517 by a...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Labels: -WebKit-ID-78858 WebKit-ID-78858-NEW

Comment #17 on issue 114517 by bugdro...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517#c17

https://bugs.webkit.org/show_bug.cgi?id=78858

[chro...@googlecode.com]

Updates:
Owner: domi...@chromium.org

Comment #18 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor

[chro...@googlecode.com]

Comment #19 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

I have done some debugging.

First, I believe the second repro ("Disable the timeouts... We now have a
static webpage.") is a separate issue. I have filed issue 129323 to track
that.

Regarding setting document.title resetting the cursor; I could repro this
in Chrome Canary Version 21.0.1147.0 on OS X 10.7.4. I could not repro this
in WebKit Nightly Version 5.1.6 (7534.56.5, r118039) on OS X 10.7.4. rniwa
– can you elaborate on "I can reproduce the same issue on WebKit"?

I did some debugging of setting the document title resetting the cursor. I
believe this is a Chromium-side bug. The cursor is being reset in this
callstack in Cocoa gubbins:

#0 0x9114363a in -[NSCursor set] ()
#1 0x91142307 in -[NSWindow(NSCarbonExtensions)
_setCursorForMouseLocation:] ()
#2 0x91135e0b in __-[NSWindow _postInvalidCursorRects]_block_invoke_1 ()
#3 0x92a47ebd in _runLoopObserverWithBlockContext ()
#4 0x92a140ce in
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#5 0x92a1400d in __CFRunLoopDoObservers ()
#6 0x929e6984 in __CFRunLoopRun ()
#7 0x929e61dc in CFRunLoopRunSpecific ()
#8 0x929e6088 in CFRunLoopRunInMode ()
#9 0x957d1723 in RunCurrentEventLoopInMode ()
#10 0x957d89b6 in ReceiveNextEventCommon ()
#11 0x957d88fa in BlockUntilNextEventMatchingListInMode ()
#12 0x9106c0d8 in _DPSNextEvent ()
#13 0x9106b942 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#14 0x91067cb1 in -[NSApplication run] ()
…

I note that the tab controller is mucking with the NSView hierarchy any
time the title changes:

#0 0x911893ef in -[NSWindow invalidateCursorRectsForView:] ()
#1 0x91182251 in -[NSView addSubview:] ()
^C#2 0x0532a37d in -[TabController setIconView:] (self=0x6d962ee0,
_cmd=0x91a4bce2Quit
) at ../../chrome/browser/ui/cocoa/tabs/tab_controller.mm:212
#3 0x05335bb0 in -[TabStripController updateFaviconForContents:atIndex:]
(self=0x6b952810, _cmd=0x8760f13, contents=0x6f84ace0, modelIndex=0)
at ../../chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm:1490
#4 0x05335d47 in -[TabStripController
tabChangedWithContents:atIndex:changeType:] (self=0x6b952810,
_cmd=0x8760feb, contents=0x6f84ace0, modelIndex=0,
change=TabStripModelObserver::ALL)
at ../../chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm:1517
#5 0x05344952 in TabStripModelObserverBridge::TabChangedAt
(this=0x6b91fe40, contents=0x6f84ace0, index=0,
change_type=TabStripModelObserver::ALL)
at ../../chrome/browser/ui/cocoa/tabs/tab_strip_model_observer_bridge.mm:82
#6 0x05457b01 in TabStripModel::UpdateTabContentsStateAt (this=0x1317eac0,
index=0, change_type=TabStripModelObserver::ALL)
at ../../chrome/browser/ui/tabs/tab_strip_model.cc:404
#7 0x0514e954 in Browser::ProcessPendingUIUpdates (this=0x13180be0)
at ../../chrome/browser/ui/browser.cc:4803
#8 0x051606d4 in base::internal::RunnableAdapter<void (Browser::*)()>::Run
(this=0xc001d3a0, object=0x13180be0) at bind_internal.h:132
#9 0x05160544 in base::internal::InvokeHelper<true, void,
base::internal::RunnableAdapter<void (Browser::*)()>, void
()(base::WeakPtr<Browser> const&)>::MakeItSo (runnable={method_ = {ptr =
85255360, ptr = 0}}, a1=@0x6d9e7d14) at bind_internal.h:880
#10 0x0516046c in base::internal::Invoker<1,
base::internal::BindState<base::internal::RunnableAdapter<void
(Browser::*)()>, void ()(Browser*), void ()(base::WeakPtr<Browser>)>, void
()(Browser*)>::Run (base=0x6d9e7d00) at bind_internal.h:1170
#11 0x027f7adb in base::Callback<void ()()>::Run (this=0xc001d644) at
callback.h:272
#12 0x027f5318 in MessageLoop::RunTask (this=0x6bc1d5e0,
pending_task=@0xc001d630) at ../../base/message_loop.cc:463
#13 0x027f56c1 in MessageLoop::DeferOrRunPendingTask (this=0x6bc1d5e0,
pending_task=@0xc001d630) at ../../base/message_loop.cc:475
#14 0x027f5c78 in MessageLoop::DoDelayedWork (this=0x6bc1d5e0,
next_delayed_work_time=0xc001d710) at ../../base/message_loop.cc:690
#15 0x027523e8 in base::MessagePumpCFRunLoopBase::RunWork (this=0x6bc1d770)
at ../../base/message_pump_mac.mm:246
...

I believe this invalidateCursorRectsForView is what is tickling Cocoa to
mess with the cursor. [NSWindow disableCursorRects] fixes the bug, but it
CodeSearch indicates that
chrome/browser/ui/cocoa/location_bar/autocomplete_text_field.mm uses cursor
rects, so I am not sure if this is a feasible solution.

[chro...@googlecode.com]

Comment #20 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

Quick update on this: Since various widgets (extensions splitter, bookmarks
bar, Omnibox styled text entry, etc.) use cursor rects for changing the
cursor, this invalidateCursorRectsForView: might be unavoidable. I have
been experimenting with creating a cursor rect for the entire extent of the
render widget host view.

This is not working reliably yet; for example, mousing from the bookmarks
bar over the web view causes the cursor to become an I-beam and the bounds
of the Omnibox I-beam cursor rect are sometimes also interpreted relative
to the render widget host view.

[chro...@googlecode.com]

Comment #21 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

My impression is that the cursor rect over the extent of the render widget
host view is pretty solid in release. So I will investigate whether the
slower message pumping in debug causes the spurious I-beam cursors in debug.

[chro...@googlecode.com]

Comment #22 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

WIP patch at <https://chromiumcodereview.appspot.com/10450012>; comments
welcome.

[chro...@googlecode.com]

Comment #23 on issue 114517 by domi...@chromium.org: Setting window title

[chro...@googlecode.com]

Updates:
Labels: -WebKit-ID-78858-NEW WebKit-ID-78858-REOPENED

Comment #24 on issue 114517 by bugdro...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517#c24

https://bugs.webkit.org/show_bug.cgi?id=78858

[chro...@googlecode.com]

Comment #25 on issue 114517 by bugdro...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517#c25

The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=140495

------------------------------------------------------------------------
r140495 | domi...@chromium.org | Tue Jun 05 00:35:44 PDT 2012

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_view_mac.mm?r1=140495&r2=140494&pathrev=140495
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_view_mac.h?r1=140495&r2=140494&pathrev=140495

Apply a CursorRect to the extent of the render widget view for web page
cursors.

BUG=114517
TEST=None


Review URL: https://chromiumcodereview.appspot.com/10450012
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #26 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

While working on this I noticed another bug where the cursor is changed as
a cursor is loaded, even if the mouse is not over the element with that
cursor. I filed issue 131150 for that. Feedback on whether it is of
interest welcome.

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #27 on issue 114517 by domi...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

I tried this in 21.0.1165.0 canary on OS X 10.7.4 and it is fixed.

[chro...@googlecode.com]

Comment #28 on issue 114517 by komoro...@chromium.org: Setting window title
resets cursor
http://code.google.com/p/chromium/issues/detail?id=114517

Just confirmed that it is fixed on Canary on Mac.

Thanks, Dominic!