1194256 - nsRange::GetStartOffset returns an int32_t from XPCOM interface, and uint32_t from webidl interface

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Nika Layzell [:nika] (ni? for response)]

The two overloads for nsRange::GetStartOffset return different types of integers:

NS_IMETHODIMP
nsRange::GetStartOffset(int32_t* aStartOffset)

uint32_t
nsRange::GetStartOffset(ErrorResult& aRv) const

As the internal storage for mStartOffset is an `int32_t`, I think the first is correct, and the second should be corrected to match it.

(NB. This also applies to GetEndOffset)

Comment 1

[Trevor Saunders (:tbsaunde)]

> As the internal storage for mStartOffset is an `int32_t`, I think the first
> is correct, and the second should be corrected to match it.

on the other hand Range.webidl expects uint32_t and I believe that came from the spec.  Of course iirc that's the editing spec which last I checked was kind of unmaintained.
>

Comment 2

[Nika Layzell [:nika] (ni? for response)]

(In reply to Trevor Saunders (:tbsaunde) from comment #1)
> > As the internal storage for mStartOffset is an `int32_t`, I think the first
> > is correct, and the second should be corrected to match it.
> 
> on the other hand Range.webidl expects uint32_t and I believe that came from
> the spec.  Of course iirc that's the editing spec which last I checked was
> kind of unmaintained.
> >

Hmm, in that case maybe we should use a uint32_t internally. I'm pretty sure that these offsets can never be negative (and if they can, then that's a problem for the spec).

Comment 3

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.