Last Comment Bug 199959 - Attribute.specified isn't true when attribute set through Attribute.value='string'
: Attribute.specified isn't true when attribute set through Attribute.value='st...
Status: RESOLVED FIXED
[good first bug]
: dom2
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: P4 normal with 3 votes (vote)
: mozilla1.9.1a1
Assigned To: Olli Pettay [:smaug] (high review load, please consider other reviewers)
:
Mentors:
javascript:var attr=document.createAt...
Depends on:
Blocks: acid3
  Show dependency treegraph
 
Reported: 2003-03-31 08:21 PST by David "liorean" Andersson
Modified: 2008-07-31 02:36 PDT (History)
13 users (show)
dao+bmo: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
possible patch (937 bytes, patch)
2008-05-13 10:41 PDT, Olli Pettay [:smaug] (high review load, please consider other reviewers)
jonas: review+
bzbarsky: superreview+
Details | Diff | Review
mochitest (1.84 KB, patch)
2008-07-10 12:29 PDT, Olli Pettay [:smaug] (high review load, please consider other reviewers)
no flags Details | Diff | Review

Description David "liorean" Andersson 2003-03-31 08:21:30 PST
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 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-03-31 11:17:02 PST
sicking?  This is all you, man.  ;)
Comment 2 Fabian Guisset 2003-04-20 07:47:31 PDT
OS->All, Hardware->All, P4, see also bug 195350
Marking NEW.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-02-14 13:19:56 PST
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).
Comment 4 David "liorean" Andersson 2004-02-14 14:42:58 PST
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.)
Comment 5 Jonas Sicking (:sicking) PTO Until July 5th 2004-02-16 10:16:52 PST
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)
Comment 6 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2008-05-13 10:41:50 PDT
Created attachment 320744 [details] [diff] [review]
possible patch

I think we could do this for now, since DTDs and Schemas aren't really supported.
Gives one point in ACID3.
Comment 7 Jonas Sicking (:sicking) PTO Until July 5th 2008-07-10 05:14:03 PDT
Comment on attachment 320744 [details] [diff] [review]
possible patch

Wow, ACID3 really tests a lot of junk
Comment 8 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2008-07-10 07:18:31 PDT
Comment on attachment 320744 [details] [diff] [review]
possible patch

You could have sr'd too ;)
Thanks.
Comment 9 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-07-10 07:45:27 PDT
Comment on attachment 320744 [details] [diff] [review]
possible patch

Meh.
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-07-10 11:16:31 PDT
Worth adding a unit test?
Comment 11 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2008-07-10 11:24:54 PDT
Well, ACID3 has a test and dom1 testsuite has other tests
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-07-10 11:56:35 PDT
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.
Comment 13 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2008-07-10 12:29:42 PDT
Created attachment 328956 [details] [diff] [review]
mochitest

I'll commit this once the tree is less orange
Comment 14 Dietrich Ayala (:dietrich) 2008-07-10 15:19:17 PDT
backed out due to orange, per sheriff myk.
Comment 15 Myk Melez [:myk] [@mykmelez] 2008-07-10 17:27:31 PDT
The patch has been cleared of culpability for the test failure and can land again when the tree reopens.

Note You need to log in before you can comment on or make changes to this bug.