[FIX]Need to properly handle attribute selectors with wildcard namespace

RESOLVED FIXED in mozilla1.5alpha

Status

()

P2
normal
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

Trunk
mozilla1.5alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

16 years ago
For some CSS selectors, the matching code needs to get a list of all attributes
with a given name (no matter what namespace they are in) from a node.  We have
something along those lines with the "attributes" property on nsIDOMNode, and I
guess the style system could use that in a pinch.  Doing things that way is
probably a little slow, though....

Do we want some sort of API on nsIContent for this?
(Assignee)

Comment 1

16 years ago
Created attachment 126259 [details]
testcase

To pass this testcase, we have to be able to examine all attributes named
"attribute", no matter what namespace they are in, and compare their values to
a given string.
If we absolutly have to have a "fast" way to do this we should IMHO add a new
function for it. I do not want to make it so that you can pass in
kNameSpaceID_Unknown or some such as namespace to the existing functions.

I think it was a bad desition by CSS group to allow this syntax (mostly because
it's very bad style to have attributes with same name but in different namespace
and give them a same/similar meaning) and I don't think it's worth taking a
performance hit to implement it.

IMHO the style-code could just loop through all attributes and call
GetAttrNameAt() until a good attribute is found 
(Assignee)

Comment 3

16 years ago
Ah.  I had missed GetAttrNameAt().  Yeah, that should be just fine for what we
need here.  Morphing and taking to do the style system end.  ;)
Assignee: bugmail → bzbarsky
Component: DOM Core → Style System
Priority: -- → P2
Summary: Need to have a way to get a list of all attrs with a given name from a node → Need to properly handle attribute selectors with wildcard namespace
Target Milestone: --- → mozilla1.5alpha
(Assignee)

Comment 4

16 years ago
A thought.  Perhaps the attr getters should assert if kNamespaceID_Unknown is
passed in for the namespace id, since the behavior is undefined?
(Assignee)

Comment 5

16 years ago
Created attachment 126329 [details] [diff] [review]
Patch using GetAttrNameAt
(Assignee)

Updated

16 years ago
Attachment #126329 - Flags: superreview?(dbaron)
Attachment #126329 - Flags: review?(dbaron)
(Assignee)

Updated

16 years ago
Summary: Need to properly handle attribute selectors with wildcard namespace → [FIX]Need to properly handle attribute selectors with wildcard namespace
(Assignee)

Comment 6

16 years ago
Created attachment 126344 [details] [diff] [review]
Patch to assert if GetAttr is called with kNamespaceID_Unknown

GetAttrNameAt patch checked in.

This one will assert in situations like the one we had here, so that should let
us find other broken callers.
Attachment #126329 - Attachment is obsolete: true
(Assignee)

Comment 7

16 years ago
Comment on attachment 126344 [details] [diff] [review]
Patch to assert if GetAttr is called with kNamespaceID_Unknown

jst, would you review?
Attachment #126344 - Flags: superreview?(jst)
Attachment #126344 - Flags: review?(jst)
Comment on attachment 126344 [details] [diff] [review]
Patch to assert if GetAttr is called with kNamespaceID_Unknown

r+sr=jst
Attachment #126344 - Flags: superreview?(jst)
Attachment #126344 - Flags: superreview+
Attachment #126344 - Flags: review?(jst)
Attachment #126344 - Flags: review+
(Assignee)

Comment 9

16 years ago
Patch checked in, with similar assertions added to HasAttr.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

16 years ago
*** Bug 169905 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.