You need to
before you can comment on or make changes to this bug.
Steps to reproduce
1. Open www.google.com
2. Choose Pinyin Simplified input method (or ITABC on Leopard)
3. Type h in the search field
4. Press Down key
5. Press delete key
Results: although text caret is at the end of completed text after step 4 (I was getting "hyundai"), the first character ("h") is deleted in step 5.
Created an attachment (id=45444) [details]
style-queue ran check-webkit-style on attachment 45444 [details] without any errors.
(From update of attachment 45444 [details])
> + // An open typing command that disagrees about current selection would cause issues with typing later on.
> + if (m_lastEditCommand && m_lastEditCommand->isTypingCommand())
> + static_cast<TypingCommand*>(m_lastEditCommand.get())->closeTyping();
I think this needs to check isOpenForMoreTyping before just calling closeTyping. Luckily there is a helper function for this. You should just write:
The class member function handles the null check too.
r=me if you change it like I suggest
> I think this needs to check isOpenForMoreTyping before just calling
I wonder why - closeTyping() just sets a boolean member value.
> r=me if you change it like I suggest
I'll make the change, if only for consistency.
(In reply to comment #4)
> > I think this needs to check isOpenForMoreTyping before just calling
> > closeTyping.
> I wonder why - closeTyping() just sets a boolean member value.
Guess you're right. Wonder why TypingCommand::closeTyping bothers to check it!