[Webkit-unassigned] [Bug 35625] Correct base/extent of selection on double-click.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 19 10:09:03 PDT 2010


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





--- Comment #7 from Ojan Vafai <ojan at chromium.org>  2010-03-19 10:09:03 PST ---
> I don't have a great answer why it makes sense to expose these positions - but
> it's definitely way too late to change the API, and the more interesting
> anchor/offset ones are already exposed.

I'd really be surprised if anyone actually uses these correctly. I'd expect
very few people to understand the difference between base/extent and
focus/anchor, so more likely, if they are using them, it's causing them bugs.

> Anchor/focus sound like they could be the same things as base/extent, but they
> actually are not. The former tell what the selection is, while the latter tell
> how it was created.

Yup. Not sure why it's worthwhile exposing this. Seems like implementation
details.

In either case, I'm more interested in us not using it internally than whether
we expose it or not. The only time we need base/extent within WebCore instead
of anchor/focus is in the EventHandler code that deals with mouse-based
selections.

How about I rework this patch to do the following:
1) Leave base/extent exposed to the web as it is currently in trunk.
2) Store anchor/focus in VisibleSelection.
3) Use anchor/focus everywhere in our code except for functions the expose
base/extent to the web.

At a quick glance at the selection code, I was able to find a bug with
base/extent. I'll attach a testcase in a sec. I'd be surprised if we didn't
have many bugs around base/extent not being at the bounds of the selection.

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



More information about the webkit-unassigned mailing list