http://bugs.winehq.org/show_bug.cgi?id=15243
Summary: Google Chrome URL bar edits and text selections always begin at start of bar Product: Wine Version: CVS/GIT Platform: Other URL: http://chrome.google.com OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: richedit AssignedTo: wine-bugs@winehq.org ReportedBy: royshea@gmail.com
Regardless of where the URL bar is clicked to begin editing or selecting text, the cursor begins the action from the start of the URL bar. Probably some sort of richedit bug.
http://bugs.winehq.org/show_bug.cgi?id=15243
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
--- Comment #1 from Austin English austinenglish@gmail.com 2008-09-11 15:08:02 --- Terminal output would help.
Have you tried native richedit to confirm this?
http://bugs.winehq.org/show_bug.cgi?id=15243
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=15243
--- Comment #2 from Roy Shea royshea@gmail.com 2008-09-12 13:30:06 --- Created an attachment (id=16044) --> (http://bugs.winehq.org/attachment.cgi?id=16044) Terminal output from selecting text in URL bar
I've confirmed that native riched20 fixes this problem. Attached is the terminal output from attempts to select text. Off the top of my head I'd say the top offenders are: ITextDocument_fnFreeze, ITextDocument_fnUnFreeze, ITextSelection_fnGetFlags, and ITextSelection_fnSetFlags.
http://bugs.winehq.org/show_bug.cgi?id=15243
--- Comment #3 from Austin English austinenglish@gmail.com 2008-09-12 15:18:08 --- (In reply to comment #2)
Created an attachment (id=16044)
--> (http://bugs.winehq.org/attachment.cgi?id=16044) [details]
Terminal output from selecting text in URL bar
I've confirmed that native riched20 fixes this problem. Attached is the terminal output from attempts to select text. Off the top of my head I'd say the top offenders are: ITextDocument_fnFreeze, ITextDocument_fnUnFreeze, ITextSelection_fnGetFlags, and ITextSelection_fnSetFlags.
Could you get a +richedit log/
http://bugs.winehq.org/show_bug.cgi?id=15243
--- Comment #4 from Roy Shea royshea@gmail.com 2008-09-12 16:00:33 --- Created an attachment (id=16053) --> (http://bugs.winehq.org/attachment.cgi?id=16053) +richedit
Adding log with +richedit.
http://bugs.winehq.org/show_bug.cgi?id=15243
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #5 from Austin English austinenglish@gmail.com 2008-09-17 21:02:23 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=15243
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|wine-bugs@winehq.org |dylan.ah.smith@gmail.com Status|NEW |ASSIGNED
--- Comment #6 from Dylan Smith dylan.ah.smith@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/...
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 <.
http://bugs.winehq.org/show_bug.cgi?id=15243
Jaime Rave jaimerave@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaimerave@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=15243
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16789|0 |1 is obsolete| |
--- Comment #7 from Dylan Smith dylan.ah.smith@gmail.com 2008-10-22 00:48:49 --- Created an attachment (id=16790) --> (http://bugs.winehq.org/attachment.cgi?id=16790) richedit: Fixed EM_POSFROMCHAR for position of text length.
Here is the updated patch that I sent to wine-patches.
It correctly accounts for the case where the position used for EM_POSFROMCHAR is greater than the text length. It adds an offset of 1 that native does for some reason.
http://bugs.winehq.org/show_bug.cgi?id=15243
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #8 from Austin English austinenglish@gmail.com 2008-10-22 02:24:39 --- Thanks Dylan! Riched has improved massively over the past few months. Keep up the great work!
http://bugs.winehq.org/show_bug.cgi?id=15243
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16790|0 |1 is obsolete| |
--- Comment #9 from Dylan Smith dylan.ah.smith@gmail.com 2008-10-22 10:16:11 --- (From update of attachment 16790) In git as 46d79b0363494426d1c41cb1eccd88f0926d83b3
I think the bug is fixed now.
http://bugs.winehq.org/show_bug.cgi?id=15243
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #10 from Austin English austinenglish@gmail.com 2008-10-22 10:43:09 --- Fixed in git.
http://bugs.winehq.org/show_bug.cgi?id=15243
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2008-10-24 11:13:54 --- Closing bugs fixed in 1.1.7.
http://bugs.winehq.org/show_bug.cgi?id=15243
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified