Bug 23853 - DOMSelection does not need a "type" member
Summary: DOMSelection does not need a "type" member
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-09 13:58 PST by Eric Seidel (no email)
Modified: 2017-07-18 08:30 PDT (History)
11 users (show)

See Also:


Attachments
Patch. (3.10 KB, patch)
2012-05-30 02:27 PDT, Antaryami Pandia (apandia)
rniwa: review-
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-04 (627.35 KB, application/zip)
2012-05-30 07:53 PDT, WebKit Review Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2009-02-09 13:58:51 PST
DOMSelection does not need a "type" member

http://trac.webkit.org/browser/trunk/WebCore/page/DOMSelection.idl

Mozilla's doesn't have one:
https://developer.mozilla.org/En/DOM/Selection

I don't think ours should either.  We'd have to add a new type when we add multi-range selection support anyway...

If anyone disagrees, I'd like to know.  I'll post a patch shortly.
Comment 1 Justin Garcia 2009-02-09 14:11:30 PST
type is a IE extension http://msdn.microsoft.com/en-us/library/ms534692(VS.85).aspx although, in IE its three possible values are none, text, and control...
Comment 2 Eric Seidel (no email) 2009-05-03 15:42:10 PDT
In later patches I've added a comment to our type() code which notes that our values are incompatible with IE's.
Comment 3 Ryosuke Niwa 2012-05-30 00:45:31 PDT
It appears to me that we should just get rid of this property. It's inconsistent with IE's and it's not standardized anywhere.
Comment 4 Antaryami Pandia (apandia) 2012-05-30 02:27:25 PDT
Created attachment 144764 [details]
Patch.
Comment 5 WebKit Review Bot 2012-05-30 07:53:36 PDT
Comment on attachment 144764 [details]
Patch.

Attachment 144764 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12853606

New failing tests:
editing/selection/5497643.html
editing/selection/5779984-1.html
editing/selection/empty-cell-right-click.html
editing/selection/context-menu-text-selection.html
fast/forms/shadow-tree-exposure.html
Comment 6 WebKit Review Bot 2012-05-30 07:53:40 PDT
Created attachment 144814 [details]
Archive of layout-test-results from ec2-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 7 Ryosuke Niwa 2012-05-30 09:41:34 PDT
Comment on attachment 144764 [details]
Patch.

It appears that there are some tests that depend on this attribute. We need to "fix" those tests as well.
Comment 8 Ojan Vafai 2012-05-30 09:51:39 PDT
Since this is removing a web-facing feature, I believe you now need to email webkit-dev first.
Comment 9 Ryosuke Niwa 2012-05-30 10:14:36 PDT
(In reply to comment #8)
> Since this is removing a web-facing feature, I believe you now need to email webkit-dev first.

Yes. See http://trac.webkit.org/wiki/DeprecatingFeatures
Comment 10 Antaryami Pandia (apandia) 2012-05-30 21:36:22 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > Since this is removing a web-facing feature, I believe you now need to email webkit-dev first.
> 
> Yes. See http://trac.webkit.org/wiki/DeprecatingFeatures

Thanks for the information. I will send an email to webkit dev first.
Comment 11 Antaryami Pandia (apandia) 2012-06-01 04:01:34 PDT
(In reply to comment #7)
> (From update of attachment 144764 [details])
> It appears that there are some tests that depend on this attribute. We need to "fix" those tests as well.

Yes. I am working to fix these failing tests. Once done I will upload the patch.