Closed
Bug 199959
Opened 21 years ago
Closed 15 years ago
Attribute.specified isn't true when attribute set through Attribute.value='string'
Categories
(Core :: DOM: Core & HTML, defect, P4)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.9.1a1
People
(Reporter: liorean, Assigned: smaug)
References
()
Details
(Keywords: dom2, Whiteboard: [good first bug])
Attachments
(2 files)
937 bytes,
patch
|
sicking
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
1.84 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Minimal testcase: var attr=document.createAttribute('title'); attr.value='titleAttributeIsSpecified'; alert(attr.specified); // => false It doesn't make any difference if I append it to an element using setAttributeNode either. Haven't tried to append through NamedNodeMap.setNamedItem, but I assume the same is the case then. Reproducible: Always Steps to Reproduce:
![]() |
||
Comment 1•21 years ago
|
||
sicking? This is all you, man. ;)
Comment 2•21 years ago
|
||
OS->All, Hardware->All, P4, see also bug 195350 Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Priority: -- → P4
Hardware: PC → All
![]() |
||
Comment 3•20 years ago
|
||
Actually, it looks like .specified on an Attr node should be "true" if it has no element, regardless of whether the attribute has any sort of value (see http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-637646024). At least if I read this spec correctly (it really doesn't seem to do a good job of addressing attributes that are not attached to elements).
Reporter | ||
Comment 4•20 years ago
|
||
Yeah, .specified should be set to true when creating the Attr node, as this passage IMO rakther clearly specifies: "If the ownerElement attribute is null (i.e. because it was just created or was set to null by the various removal and cloning operations) specified is true." Appending to an element SHOULD make no difference, but I tested it just to check that the behavior was the same. In moz it currently, wrongly, alerts false. (As a note, iem and iew alerts false. Op7 and saf alerts true.)
Mozilla currently doesn't do anything proper when it comes to .specified. We don't at all keep track of which attributes comes from default values and which were explcitly set. There is some code that is executed when getting .specified, but it looks like the person who wrote that totally missunderstood what it was supposed to be. The code looks if the attribute is set on the element or not, which of course is compleatly wrong. Anyhow, my recommendation is to not use .specified at all in mozilla, there is no support for it currently and I don't think it's very high up on anybodys priority-list. The problem is implementing .specified without adding bloat or reducing speed of other operations. Does anyone have a usecase where .specified is really needed, or is this strictly a correctness request? (not saying that correctness isn't important, just saying that there might be more important things out there)
Assignee | ||
Comment 6•16 years ago
|
||
I think we could do this for now, since DTDs and Schemas aren't really supported. Gives one point in ACID3.
Comment on attachment 320744 [details] [diff] [review] possible patch Wow, ACID3 really tests a lot of junk
Attachment #320744 -
Flags: review?(jonas) → review+
Assignee | ||
Comment 8•15 years ago
|
||
Comment on attachment 320744 [details] [diff] [review] possible patch You could have sr'd too ;) Thanks.
Attachment #320744 -
Flags: superreview?
![]() |
||
Comment 9•15 years ago
|
||
Comment on attachment 320744 [details] [diff] [review] possible patch Meh.
Attachment #320744 -
Flags: superreview? → superreview+
Assignee | ||
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•15 years ago
|
||
Well, ACID3 has a test and dom1 testsuite has other tests
![]() |
||
Comment 12•15 years ago
|
||
Ok, as long as we have an automated test for this in our tests we run on tinderbox, please flag in-testsuite+. If we don't, we need one.
Assignee | ||
Comment 13•15 years ago
|
||
I'll commit this once the tree is less orange
Comment 14•15 years ago
|
||
backed out due to orange, per sheriff myk.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 15•15 years ago
|
||
The patch has been cleared of culpability for the test failure and can land again when the tree reopens.
Comment 16•15 years ago
|
||
http://hg.mozilla.org/index.cgi/mozilla-central/rev/f08f6a21deb7
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a1
You need to log in
before you can comment on or make changes to this bug.
Description
•