Comment #22 on issue 17803 by [email protected]: On gmail, focus
unexpectedly jumps to the location bar every now and then and location bar
is focussed on every tab switch
http://code.google.com/p/chromium/issues/detail?id=17803
I did some research on how to desymbolize the stacks I posted above. This
is possible using `dwarfdump`, when you have the dSYM files for our build.
They
are stored somewhere, and it's possible to get them.
I wrote a small python script that symbolizes the interesting parts of the
stacks. I attached both the python script and its output to this post (I
did some
postprocessing on the output using vim and c++filt and prepended that to
the output file. The unmodified output is at the end of the file, but it's
a bit of a
nuisance to read).
Here's one of the stacks from the file above:
1 30485 -setSelectedRange::entry
AppKit`-[NSTextView(NSSharing) setSelectedRange:]
AppKit`-[NSLayoutManager
textStorage:edited:range:changeInLength:invalidatedRange:]+0x214
AppKit`-[NSTextStorage
_notifyEdited:range:changeInLength:invalidatedRange:]+0x90
AppKit`-[NSTextStorage processEditing]+0xd9
AppKit`-[NSTextStorage edited:range:changeInLength:]+0x122
Foundation`-[NSConcreteMutableAttributedString
replaceCharactersInRange:withAttributedString:]+0xf9
AppKit`-[NSConcreteTextStorage
replaceCharactersInRange:withAttributedString:]+0x6b
Foundation`-[NSMutableAttributedString
setAttributedString:]+0x6a
AppKit`syncTextWithTextView+0x26c
AppKit`_NSEditTextCellWithOptions+0x613
AppKit`-[NSTextFieldCell
_selectOrEdit:inView:target:editor:event:start:end:]+0x16d
AppKit`-[NSCell
selectWithFrame:inView:editor:delegate:start:length:]+0x56
PrintingCocoaPDEs`0x7578d91
AppKit`-[NSTextField selectText:]+0xe2
AppKit`-[NSTextField becomeFirstResponder]+0x87
AppKit`-[NSWindow makeFirstResponder:]+0x12e
Google Chrome Framework`ChromeMain+0x6213e
Google Chrome Framework`ChromeMain+0x5f4f5
Google Chrome Framework`ChromeMain+0x61eed
Google Chrome Framework`ChromeMain+0x61fd2
Here's the interesting part of the symbolized version of this stack (the
four lines at the bottom):
MIPS linkage
name(
"AutocompleteEditViewMac::SetWindowTextAndCaretPos(std::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >
const&, unsigned long)" )
MIPS linkage name( "AutocompleteEditModel::Revert()" )
MIPS linkage name( "AutocompleteEditViewMac::RevertAll()" )
MIPS linkage name( "AutocompleteEditViewMac::Update(TabContents const*)" )
SetWindowTextAndCaretPos() calls SetSelectedRange() (which was probably
inlined), which contains the following logic:
if (model_->has_focus()) {
// TODO(shess): If |model_| thinks we have focus, this should not
// be necessary. Try to convert to DCHECK(IsFirstResponder()).
if (![field_ currentEditor]) {
[[field_ window] makeFirstResponder:field_];
}
...
}
So one theory would be that |model_->has_focus()| gets corrupted at some
point. The gtk and win versions of autocomplete_edit_view do not check
|model_->has_focus()| for selection, which would explain why this problem
doesn't surface there.
cc'ing pkasting who wrote the model code loooong ago. Peter, did you hear
something like this before?
Attachments:
symbolize_dtrace.py 1.1 KB
stack_symbols.txt 237 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
