Bug 66014 - Get rid of calls to deprecatedNode and deprecatedEditingOffset in AccessibilityRenderObject.cpp and InsertTextCommand.cpp
Summary: Get rid of calls to deprecatedNode and deprecatedEditingOffset in Accessibili...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords:
Depends on:
Blocks: 52099
  Show dependency treegraph
 
Reported: 2011-08-10 14:48 PDT by Ryosuke Niwa
Modified: 2011-08-17 10:27 PDT (History)
6 users (show)

See Also:


Attachments
refactoring (7.09 KB, patch)
2011-08-10 14:58 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
fixed build failure (7.29 KB, patch)
2011-08-10 15:18 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
Made Position::rootEditableElement() const (7.29 KB, patch)
2011-08-16 16:01 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-08-10 14:48:39 PDT
Some low hanging fruits here.
Comment 1 Ryosuke Niwa 2011-08-10 14:58:29 PDT
Created attachment 103538 [details]
refactoring
Comment 2 Gyuyoung Kim 2011-08-10 15:04:49 PDT
Comment on attachment 103538 [details]
refactoring

Attachment 103538 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/9344306
Comment 3 Early Warning System Bot 2011-08-10 15:06:58 PDT
Comment on attachment 103538 [details]
refactoring

Attachment 103538 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/9344307
Comment 4 Ryosuke Niwa 2011-08-10 15:18:14 PDT
Created attachment 103539 [details]
fixed build failure
Comment 5 Hajime Morrita 2011-08-15 21:17:12 PDT
Comment on attachment 103539 [details]
fixed build failure

View in context: https://bugs.webkit.org/attachment.cgi?id=103539&action=review

> Source/WebCore/dom/Position.h:131
> +    Element* rootEditableElement()

const?

> Source/WebCore/dom/Range.h:106
> +    void setStart(const Position&, ExceptionCode&);

You can give ASSERT_NO_EXCEPTION for the default value of the second parameter.
Comment 6 Ryosuke Niwa 2011-08-16 16:01:41 PDT
Created attachment 104112 [details]
Made Position::rootEditableElement() const
Comment 7 Hajime Morrita 2011-08-16 23:12:47 PDT
Comment on attachment 104112 [details]
Made Position::rootEditableElement() const

OK once all bots pass.
Comment 8 Ryosuke Niwa 2011-08-16 23:33:46 PDT
Thanks for the review!
Comment 9 WebKit Review Bot 2011-08-17 03:52:15 PDT
Comment on attachment 104112 [details]
Made Position::rootEditableElement() const

Clearing flags on attachment: 104112

Committed r93199: <http://trac.webkit.org/changeset/93199>
Comment 10 WebKit Review Bot 2011-08-17 03:52:20 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Darin Adler 2011-08-17 10:24:02 PDT
Comment on attachment 104112 [details]
Made Position::rootEditableElement() const

View in context: https://bugs.webkit.org/attachment.cgi?id=104112&action=review

> Source/WebCore/dom/Range.cpp:287
> +void Range::setStart(const Position& start, ExceptionCode& ec)
> +{
> +    Position parentAnchored = start.parentAnchoredEquivalent();
> +    setStart(parentAnchored.containerNode(), parentAnchored.offsetInContainerNode(), ec);
> +}
> +
> +void Range::setEnd(const Position& end, ExceptionCode& ec)
> +{
> +    Position parentAnchored = end.parentAnchoredEquivalent();
> +    setStart(parentAnchored.containerNode(), parentAnchored.offsetInContainerNode(), ec);
> +}

Do callers really need the exception capability? Instead could we just have these fail silently or assert?
Comment 12 Ryosuke Niwa 2011-08-17 10:25:55 PDT
Comment on attachment 104112 [details]
Made Position::rootEditableElement() const

View in context: https://bugs.webkit.org/attachment.cgi?id=104112&action=review

>> Source/WebCore/dom/Range.cpp:287
>> +}
> 
> Do callers really need the exception capability? Instead could we just have these fail silently or assert?

We can do that.  Or pass ASSERT_NO_EXCEPTION by default as morrita suggested.
Comment 13 Darin Adler 2011-08-17 10:27:49 PDT
Generally, the ExceptionCode& thing should only be used for actual DOM binding since it’s how the DOM cis specified. Not internal use, because it’s an awkward way to report errors in C++.

ASSERT_NO_EXCEPTION is a fine way to make a function that’s intended for DOM binding easier to use internally. But a function intended for user internally probably should not even use ExceptionCode&.