Bug 62954 - add/removeSpellcheckRange use RefPtr incorrectly for arguments
Summary: add/removeSpellcheckRange use RefPtr incorrectly for arguments
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-19 13:12 PDT by Darin Adler
Modified: 2011-12-21 21:17 PST (History)
5 users (show)

See Also:


Attachments
A quick patch v0 (8.51 KB, patch)
2011-06-20 05:19 PDT, Hironori Bono
no flags Details | Formatted Diff | Diff
A quick patch v1 (8.80 KB, patch)
2011-06-20 18:09 PDT, Hironori Bono
darin: review-
darin: commit-queue-
Details | Formatted Diff | Diff
A quick fix v2 (8.05 KB, patch)
2011-06-21 00:31 PDT, Hironori Bono
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2011-06-19 13:12:18 PDT
Arguments should be PassRefPtr or raw pointers, never RefPtr.
Comment 1 Hironori Bono 2011-06-20 05:19:53 PDT
Created attachment 97783 [details]
A quick patch v0

Greetings,

(In reply to comment #0)
> Arguments should be PassRefPtr or raw pointers, never RefPtr.

Thank you for noticing it. I have replaced all the RefPtr arguments in my r88332: <http://trac.webkit.org/changeset/88332> with PassRefPtr. (Even though I have not tried this change on valgrind, I think this change works without memory leaks.) It would be definitely helpful to give me feedback.

Regards,

Hironori Bono
Comment 2 Darin Adler 2011-06-20 09:43:23 PDT
Comment on attachment 97783 [details]
A quick patch v0

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

> Source/WebCore/dom/DocumentMarkerController.cpp:686
> +bool DocumentMarkerController::addUserSpellingMarker(Node* node, unsigned start, unsigned length, PassRefPtr<DOMStringList> srcSuggestions, unsigned options)

The prefix we use here is “prp”, not “src”.
Comment 3 Hironori Bono 2011-06-20 18:09:42 PDT
Created attachment 97900 [details]
A quick patch v1

Greetings Darin,

(In reply to comment #2)
> (From update of attachment 97783 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=97783&action=review
> 
> > Source/WebCore/dom/DocumentMarkerController.cpp:686
> > +bool DocumentMarkerController::addUserSpellingMarker(Node* node, unsigned start, unsigned length, PassRefPtr<DOMStringList> srcSuggestions, unsigned options)
> 
> The prefix we use here is “prp”, not “src”.

Thank you for noticing it. (I'm a little wondering why check-webkit-style did not notice it, though. It may be a good idea to write a change for it?) I have updated this change to use prp prefixes for PassRefPtr arguments. Is it possible to review the updated one?

Regards,

Hironori Bono
Comment 4 Darin Adler 2011-06-20 19:24:51 PDT
Comment on attachment 97900 [details]
A quick patch v1

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

I’d prefer to see a function that makes removeSpellcheckRange use a raw pointer.

> Source/WebCore/html/HTMLDivElement.cpp:94
> -void HTMLDivElement::addSpellcheckRange(unsigned long start, unsigned long length, RefPtr<DOMStringList> suggestions, unsigned short options)
> +void HTMLDivElement::addSpellcheckRange(unsigned long start, unsigned long length, PassRefPtr<DOMStringList> prpSuggestions, unsigned short options)
>  {
> -    document()->markers()->addUserSpellingMarker(this, start, length, suggestions, options);
> +    document()->markers()->addUserSpellingMarker(this, start, length, prpSuggestions, options);
>  }

Here there is no reason to change the name of the argument. Just “suggestions” would be fine. Same for the other overrides of this function.

> Source/WebCore/html/HTMLDivElement.h:45
> +    void removeSpellcheckRange(PassRefPtr<SpellcheckRange>);

I don’t understand why the remove function takes a PassRefPtr. The caller is not passing ownership in, so I’d think we could just use a raw pointer. Is there some problem with DOM bindings that means we have to use PassRefPtr here?
Comment 5 Hironori Bono 2011-06-21 00:31:39 PDT
Created attachment 97944 [details]
A quick fix v2

Greetings Darin,

Thank you for your review and comments.

(In reply to comment #4)
> (From update of attachment 97900 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=97900&action=review
> 
> I’d prefer to see a function that makes removeSpellcheckRange use a raw pointer.

Thank you for noticing it. I have replaced its parameter from PassRefPtr to a raw pointer.
 
> > Source/WebCore/html/HTMLDivElement.cpp:94
> > -void HTMLDivElement::addSpellcheckRange(unsigned long start, unsigned long length, RefPtr<DOMStringList> suggestions, unsigned short options)
> > +void HTMLDivElement::addSpellcheckRange(unsigned long start, unsigned long length, PassRefPtr<DOMStringList> prpSuggestions, unsigned short options)
> >  {
> > -    document()->markers()->addUserSpellingMarker(this, start, length, suggestions, options);
> > +    document()->markers()->addUserSpellingMarker(this, start, length, prpSuggestions, options);
> >  }
> 
> Here there is no reason to change the name of the argument. Just “suggestions” would be fine. Same for the other overrides of this function.

Oops, it seems a script used for creating this change replaced this parameter as well. I have removed them.
 
> > Source/WebCore/html/HTMLDivElement.h:45
> > +    void removeSpellcheckRange(PassRefPtr<SpellcheckRange>);
> 
> I don’t understand why the remove function takes a PassRefPtr. The caller is not passing ownership in, so I’d think we could just use a raw pointer. Is there some problem with DOM bindings that means we have to use PassRefPtr here?

Sorry for my confusing change. If I recall correctly, I used RefPtr here just because I saw a valgrind error when implementing r88332. But, I cannot see any valgrind errors when I run this change on valgrind now. (Probably I misread another valgrind error.) I have replaced PassRefPtr with a raw pointer since it does not cause any valgrind errors any longer.

Regards,

Hironori Bono
Comment 6 Hironori Bono 2011-06-21 00:33:43 PDT
Greetings,

Sorry, I have uploaded a wrong patch. I will upload the correct soon.

Regards,

Hironori Bono
Comment 7 Simon Fraser (smfr) 2011-06-21 21:03:51 PDT
Comment on attachment 97944 [details]
A quick fix v2

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

> Source/WebCore/dom/DocumentMarkerController.cpp:687
>  {

drop the 'prp'. We don't use Hungarian notation.
Comment 8 Darin Adler 2011-06-21 23:06:11 PDT
Simon, we do use prp for PassRefPtr, even though we make no other uses of Hungarian notation. It’s mentioned here <http://www.webkit.org/coding/RefPtr.html> in the section labeled “Function arguments”.
Comment 9 Eric Seidel (no email) 2011-12-21 15:24:27 PST
Comment on attachment 97944 [details]
A quick fix v2

I believe Darin answered simon's concern.  marking cq+ (Since the author is not a committer).
Comment 10 WebKit Review Bot 2011-12-21 15:29:06 PST
Comment on attachment 97944 [details]
A quick fix v2

Rejecting attachment 97944 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:
nputElement.h.rej
patching file Source/WebCore/html/HTMLTextAreaElement.cpp
Hunk #1 FAILED at 455.
1 out of 1 hunk FAILED -- saving rejects to file Source/WebCore/html/HTMLTextAreaElement.cpp.rej
patching file Source/WebCore/html/HTMLTextAreaElement.h
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED -- saving rejects to file Source/WebCore/html/HTMLTextAreaElement.h.rej

Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Simon Fraser', u'--for..." exit_code: 1

Full output: http://queues.webkit.org/results/10998131
Comment 11 Hironori Bono 2011-12-21 18:22:13 PST
Greetings,

Sorry for the lack of updates. My change that added add/removeSpellcheckRange has been rolled out, i.e. this issue is obsolete.

Regards,

Hironori Bono