[Webkit-unassigned] [Bug 69137] In input field caret is not blinking after context menu hide

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Ryosuke Niwa <rniwa at webkit.org>  2011-10-17 23:35:06 PST ---
(In reply to comment #12)
> > This function name seems too general to me. I would name to respondToContextMenuDismiss or something like that to avoid tying it to 
> This function can be general to accept true/false.
> caret blinking.

I don't think that's a good idea. I don't want WebKit code start suspend/resume caret blinking at random timing. We should keep encapsulate the timing inside WebCore.

> > This is not right. We've already suspended caret blinking on keydown. We shouldn't be suspending caret blinking here again.
> 
> In chromium win port, context menu created in mouse up where we resumes the caret blink. As a result of this caret blinks though context menu shown. This behavior differs with IE and native application in windows. To fix this its better to suspends the caret blink in showContextMenu.

Are you saying that the context menu is created on mouse up? Are you saying that Chromium Win's current behavior matches native Windows apps' behaviors?

Then where is such a logic implemented? I'd think that we should move this logic to EventHandler and make it depend on editing behavior.

> > This function must be renamed to reflect the fact it's called when context menu is closed. It also shouldn't take a bool.
> 
> This function can call with either true or false as I explained it above to fix the issue in chromium win port. If we don't want to alter the behavior in chromium win port, this can be done.

I repeat myself that I don't want to provide such a generic method to WebKit layer.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.