Bug 6632 - REGRESSION: Selection includes spaces that it shouldn't
Summary: REGRESSION: Selection includes spaces that it shouldn't
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Justin Garcia
URL: http://www.schepers.cc/comiclinks.html
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-17 17:44 PST by Justin Garcia
Modified: 2006-01-17 21:41 PST (History)
0 users

See Also:


Attachments
reduction (1.49 KB, text/html)
2006-01-17 19:45 PST, Justin Garcia
no flags Details
patch (3.88 KB, patch)
2006-01-17 20:42 PST, Justin Garcia
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Garcia 2006-01-17 17:44:16 PST
Do a Find for "SVG".  Use Command-G to find it again.
Shrink the window, so that the occurrence of 'SVG' that was found is at the beginning of the line.
The selection will now contain the space before the beginning of the line.  Trying to reselect 'SVG' won't fix 
the problem.  It is impossible to select just 'SVG'.
Comment 1 Justin Garcia 2006-01-17 19:00:43 PST
See:

<rdar://problem/4407845> REGRESSION (TOT): blank space before found text selected at http://
www.schepers.cc/comiclinks.html
Comment 2 Justin Garcia 2006-01-17 19:45:03 PST
Created attachment 5749 [details]
reduction
Comment 3 Justin Garcia 2006-01-17 20:42:01 PST
Created attachment 5751 [details]
patch

What do you give to the function that already has everything?

p.downstream() and p.upstream() shouldn't return positions that aren't visually
equivalent.  By "visually equivalent" I mean two positions where
VisiblePosition(a) == VisiblePosition(b).

Also includes a change to VisiblePosition::previous that wasn't really
necessary for the fix:
When moving backward through the DOM using Position::previous, don't return the
first candidate found, because it may be visually equivalent to the original
(and we don't want VisiblePosition::previous returning something visually
equivalent).  
I think that the code assumed that the leftmost candidate was always chosen as
the canonical position in VisiblePosition::init (in which case the first
candidate found when moving backward would always be visually distinct from the
original).  The leftmost candidate is usually chosen, but not always.  In fact,
see <http://bugzilla.opendarwin.org/show_bug.cgi?id=6476>.
Comment 4 Darin Adler 2006-01-17 21:17:58 PST
Comment on attachment 5751 [details]
patch

r=me