Clean CompareFormControlPosition in nsHTMLFormElement.cpp

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
7 years ago
7 years ago

People

(Reporter: mounir, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
It should return a bool instead of a PRInt32. In addition, I do not really see the point with the second assert.
Could look up blame on it to see whether there was a point....
(Reporter)

Comment 2

7 years ago
http://hg.mozilla.org/mozilla-central/diff/59a540e22014/content/html/content/src/nsHTMLFormElement.cpp

Refactored from an if checking for parents and if no parents, calling the method to an asserts with this comment removed:
>  // We check that the parent of both content nodes is non-null here, because
>  // newly created form control elements may not be in the parent form
>  // element's DOM tree yet. This prevents an assertion in CompareTreePosition.
>  // See Bug 267511 for more information.

Looking at the code, this should not happen. At bind to tree, we are attached to the form if we found it as a parent so this method should not be called with an isolated element.

I'm not sure if we should keep these asserts because it sounds a bit useless today and I guess it might have been a real issue a few years ago. For control1 != control2, I guess we can keep it, that sounds sane.
(Reporter)

Updated

7 years ago
Whiteboard: [mounir-pg2]
You need to log in before you can comment on or make changes to this bug.