[Webkit-unassigned] [Bug 109404] Add selectTrailingWhitespaceEnabled setting to WebCore::Page

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Mar 6 11:23:59 PST 2013


--- Comment #29 from Tony Chang <tony at chromium.org>  2013-03-06 11:26:21 PST ---
(From update of attachment 191692)
View in context: https://bugs.webkit.org/attachment.cgi?id=191692&action=review

> Source/WebCore/page/Settings.in:199
> +# smartInsertDeleteEnabled and selectTrailingWhitespaceEnabled are mutually
> +# exclusive, meaning that enabling one will disable the other.

This seems like a new behavior and I'm not sure how you would enforce this for all ports.  For example, in Chromium, the current behavior is:

bool RenderViewImpl::isSmartInsertDeleteEnabled() {
#if defined(OS_MACOSX)
  return true;
  return false;

bool RenderViewImpl::isSelectTrailingWhitespaceEnabled() {
#if defined(OS_WIN)
  return true;
  return false;

Which means on Chromium Linux, both are false.

> Source/WebKit/chromium/public/WebSettings.h:150
> +    virtual void setSelectTrailingWhitespaceEnabled(bool) = 0;

I don't think we need to add an API for this since I don't think we plan on changing these during runtime.  The exception is for DRT, but that can use the WebCore Internals API.

> Source/WebKit/chromium/public/WebViewClient.h:-190
> -    virtual bool isSmartInsertDeleteEnabled() { return true; }
> -    virtual bool isSelectTrailingWhitespaceEnabled() { return true; }

The problem with removing this is that we'll no longer get the correct behavior in Chromium, which overrides these virtual methods-- see the RenderViewImpl snippet above.  As long as we retain the correct behavior, it's OK to remove this.

There are a couple ways you could do this, (1) Find a good time to set this (maybe WebViewImpl's constructor?) or (2) set the right default value in Settings.cpp (e.g., see defaultUnifiedTextCheckerEnabled in Settings.cpp and Settings.in).

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