I'd really like to deCOMify nsIForm a bit, and I'm not sure why the Firefox password manager is using it... It looks like it wants ResolveName, but wouldn't calling GetNamedItem on form.elements give the same result, with only frozen APIs being used? Similarly, the indexing stuff could work with frozen APIs through form.elements...
Given how much people copy our code in their extensions, I'd really like to see this fixed... Firefox-specific code just should not be using unfrozen semi-private layout interfaces when there are frozen DOM equivalents.
Flags: blocking-aviary2.0? → blocking-aviary2.0+
OS: Linux → All
Hardware: PC → All
I started looking into doing this, but I couldn't find a good DOM way to retrieve the index of an element in an HTMLCollection, or to get it's neighboring nodes. The current method of searching forwards and then backwards from a given element requires that.
Hmm.. I guess just manually doing IndexOf() (via linear search) here would be a little slow due to all the addrefs, eh? jst, would it make sense to have an nsIDOMNSHTMLCollection or something that exposes an indexOf()-like method?
bz, this is about deCOM, which would be trunk only, I'd imagine. Any reason to fix this on branch or can this drop off the Fx2 list?
clearing this off the list for now. Boris, if this is important on the 1.8.1 path, please mark it blocking again.
Yeah, this is not relevant to FF 2. I'd still like to see this fixed on trunk, though... I won't have a chance to do it, but it'd be nice if someone did...
This was fixed as a side effect of moving password manger to JS, in bug 374723.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 374723
Resolution: --- → FIXED
sweet sweet byproducts
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.