Comment #19 on issue 114517 by domin...@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.
