[Bug 15243] Google Chrome URL bar edits and text selections always begin at start of bar

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=15243


Dylan Smith <dylan.ah.smith at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|wine-bugs at winehq.org        |dylan.ah.smith at gmail.com
             Status|NEW                         |ASSIGNED




--- Comment #6 from Dylan Smith <dylan.ah.smith at gmail.com>  2008-10-21 23:38:24 ---
Created an attachment (id=16789)
 --> (http://bugs.winehq.org/attachment.cgi?id=16789)
richedit: Possible fix for EM_POSFROMCHAR for end of text

I first noticed the problem by looking at the logs, and I noticed the
WM_LBUTTONDOWN was received by Chrome's window proc with a positive x value,
then called Wine's richedit window proc with 0 for it's x value.

Google Chromium's source code helped me understand what was happening.
See:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_edit.cc?view=markup

Notice in AutocompleteEditView::OnLButtonDown the following lines, which calls
Wine's window proc using an x value that is clipped to the visible text.

  DefWindowProc(WM_LBUTTONDOWN, keys,
                MAKELPARAM(ClipXCoordToVisibleText(point.x, is_triple_click),
                           point.y));

In AutocompleteEditView::ClipXCoordToVisibleText I found that it clipped the
left and right side of the text.  The right side appeared the most interesting:

  // See if we need to clip to the right edge of the text.
  const int length = GetTextLength();
  // Asking for the coordinate of any character past the end of the text gets
  // the pixel just to the right of the last character.
  const int right_bound = std::min(r.right, PosFromChar(length).x);
  if ((length == 0) || (x < right_bound))
    return x;

I then found the problem in EM_POSFROMCHAR.  It had the following conditional
statement:
if (nCharOfs < nLength) {
    ...
} else {
    pt.x = 0;
    pt.y = editor->pBuffer->pLast->member.para.pt.y;
}

So it ends up returning a point with x=0 for the end of the text, and google
chrome uses this value to clip the x position to 0 for the mouse message,
leading to selections with the mouse that always start from the start of the
text.

I'll have to test to make sure, but I think the condition should be a <=
comparison instead of <.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.