Closed Bug 27327 Opened 25 years ago Closed 24 years ago

Input:SetAttribute('value') doesn't update content model

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: pollmann, Assigned: pollmann)

References

()

Details

Attachments

(13 files)

463 bytes, text/html
Details
412 bytes, text/html
Details
761 bytes, text/html
Details
954 bytes, text/html
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
40 bytes, text/x-review-board-request
Details
From Bug Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.12-20 i686)
BuildID:    
Input:SetAttribute('value') calls SetValue but doesn't call
mInner.SetAttribute('value').  Thus, it doesn't update the content model.  This
causes GetAttribute('value') (aka defaultValue) to not be updated.

Reproducible: Always
Steps to Reproduce:
1. Visit URL
2. Click on Add Title
3. Watch alert box pop up.
Actual Results:  Alert box is empty
Expected Results:  Alert box should say "Main Title"
Oops, the Bug Helper gave this to V not me.  :)
Assignee: vidur → pollmann
Whiteboard: Fix in hand.
Target Milestone: M14
Attached file Reduced test case
Status: NEW → ASSIGNED
Whiteboard: Fix in hand. → Fix in hand. (Reviewed, ready to check in)
Fix checked in.  To verify, pull up the Reduced test case above.  Click on the 
button.  You should see two strings dumped to the console.  Both should say Main 
Title.  Thanks!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
getAttribute("value") seems to be broken now.



This is with M14 compiled under FreeBSD -current



(which seems to have the bogus Build ID: 1999122808 even though the CVS/Tag

files indicate TSeaMonkey_M14_no_crypto_RELEASE)

There may be another bug floating around, but I can't seem to isolate it.  I've 
posted a new version of my page at http://segment7.net/php3/newpage.html that 
does not return anything from the form input elements.  To illustrate:

1) Load up the page
2) Click add item
3) Click set title
4) Change the text "New Item 0" to something else
5) Click set title again
6) A dialog box appears with various properties, notice that the "value" field 
still contains "New Item 0"

I've been trying to isolate this bug, but I haven't managed to yet.
Thanks drbrain - reopening bug per your comments.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Whiteboard: Fix in hand. (Reviewed, ready to check in)
Target Milestone: M14 → M15
Moving out to M17.
Target Milestone: M15 → M17
For inputs of type text, .value is working as of 2000-04-07, but not 
getAttribute("value")

For textarea, neither .value nor .getAttribute("value") are working.

I'll put in a combined testcase shortly.
My mistake, textarea.value is working.

Sorry for the spam
Rescheduling
Target Milestone: M17 → M19
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
Mass update of qa contact
QA Contact: gerardok → janc
Since it has been more than 9 months since the last testcase, I decided to make
a new one. I was about to report this bug in Moz 0.9, I am a bit surprised it
has first been reported so long ago.

Also, maybe the summary should mention getAttribute().

In the following testcase, when you change the input's value by typing new text,
getAttribute("value") will return the initial value of the textBox.

By using setAttribute() to change the input's value, getAttribute("value")
returns the right value.
this sounds fairly serious.  eric, any chance you could look at this and see if
it's a quick fix?
Sorry for mentionning Moz 0.9, I meant of course Moz 0.7 (build 2001010901).
Popping back off the future list.  Yep, this is potentially bad...
Target Milestone: Future → mozilla0.9
> In the following testcase, when you change the input's value by typing new
> text, getAttribute("value") will return the initial value of the textBox.
>
> By using setAttribute() to change the input's value, getAttribute("value")
> returns the right value.

Actually, this is exactly the right behaviour according to the DOM spec.  There
are actually two different concepts of "value" for inputs.  There is foo.value,
which is the current state of the text input and foo.defaultValue, which is the
initial value of the input.  This defaultValue corresponds to
getAttribute('value').  I know it's confusing - I struggled with this too, but
here are the relevent quotes from the DOM 2 WD:

defaultValue of type DOMString
 When the type attribute of the element has the value "Text", "File" or
 "Password", this represents the HTML value attribute of the element. The value
 of this attribute does not change if the contents of the corresponding form
 control, in an interactive user agent, changes. Changing this attribute,
 however, resets the contents of the form control. See the value attribute
 definition in HTML 4.0.

value of type DOMString
 When the type attribute of the element has the value "Text", "File" or
 "Password", this represents the current contents of the corresponding form
 control, in an interactive user agent. Changing this attribute changes the
 contents of the form control, but does not change the value of the HTML value
 attribute of the element. When the type attribute of the element has the value
 "Button", "Hidden", "Submit", "Reset", "Image", "Checkbox" or "Radio", this
 represents the HTML value attribute of the element...

Since we are in fact doing the right thing here, according to the Spec, I'm
marking re-closing this bug as fixed (as it was before).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
we need to document this! For once I think the specs are badly designed, this is
totally non intuitive to the user
Agreed to the fact this must be documented.

Being a web developper, me and my co-workers initially thought this was a bug,
and I don't think we'll be the only ones to think so. Add to this the fact that
IE5.5 does not behave similarly, it is very confusing.

So what happens when obj.setAttribute('value', 'value') is called? Does
obj.defaultValue gets updated? Then we could potentially have three diggerent
values fot obj.defaultValue, obj.getAttribute('value') and obj.value

Confusing isn't it?


> we need to document this!

It is sort of documented... in the DOM 2 spec.  Admittedly though, it takes
quite a bit of thinking through the wording to understand what was intended! :S

> So what happens when obj.setAttribute('value', 'value') is called? Does
> obj.defaultValue gets updated?

Yes.  obj.defaultValue is just a shorthand for obj.setAttribute('value',
'value').  This (either one) is the way to set the default, initial value of the
form element - it actually changes the "value" attribute we store in the content
model for the document.

> Then we could potentially have three diggerent values fot obj.defaultValue,
> obj.getAttribute('value') and obj.value

There are only two values:

 1) The default, initial value, which is the "value" attribute of the element in
the content model of the document.  Think of this as the actual <input type=text
*value=foo*> that you are changing.  It is accessed by
obj.get/setAttribute('value'...) or the shorthand obj.defaultValue.

If you were to click a Reset button on the form after changing the "value"
attribute as above, we would reset the form control to the newly changed
attribute, not the one in the document on the server.

 2) The current state of the form control widget.  This is what the user has
typed into the form control up to that point.  Typing into the form control does
not change the content model that we store in memory for the document, so this
is a separate thing.  It is accessed by obj.value.

I agree the naming of these does not make their purpose clear.  If it had been
up to me (or perhaps even if the DOM and HTML specs were developed at the same
time), the HTML attribute might have been called "defaultvalue", i.e. <input
type=text defaultvalue=foo>, then obj.defaultValue,
obj.setAttribute('defaultvalue', ...) and obj.value would make more sense!

*** Bug 67560 has been marked as a duplicate of this bug. ***
Component: DOM Level 1 → DOM HTML
QA contact Update
QA Contact: janc → desale
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
verified win2k 2001-10-17-18. adding the keyword vtrunk
Keywords: vtrunk
verified 2002-11-03-08
Status: RESOLVED → VERIFIED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
Bug 1102924 - Follow-up: tidying in BrowserDatabaseHelper.
Bug 1102924 - Follow-up: muffle exceptions when ending transaction during migration of search history.

I'm in two minds about this.

Because this method is called only during upgrade, we don't have to worry about
contention. Most exceptions thrown here, then, will be transient -- a stale
database lock, for example. So perhaps it makes more sense to fail the upgrade
and retry later.

This will do for now, though.
Bug 1102924 - Follow-up: use the Searches interface instead of directly accessing the ContentProvider.
No bug - Implement extraction, parsing, and checking of sqlite version numbers.

Some features, such as partial indices, require the cautious user to check for
support via SQLite version number.
Comment on attachment 8696515 [details]
MozReview Request: Bug 1102924 - Follow-up: fix syntax of UPDATE for LAST_USED.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27341/diff/1-2/
Attachment #8696515 - Attachment description: MozReview Request: Bug 1102924 - Follow-up: fix tests. → MozReview Request: Bug 1102924 - Follow-up: fix syntax of UPDATE for LAST_USED.
Comment on attachment 8696516 [details]
MozReview Request: Bug 1102924 - Follow-up: fix tests.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27343/diff/1-2/
Attachment #8696516 - Attachment description: MozReview Request: Bug 1102924 - Follow-up: review comments. → MozReview Request: Bug 1102924 - Follow-up: fix tests.
Comment on attachment 8696517 [details]
MozReview Request: Bug 1102924 - Follow-up: review comments.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27345/diff/1-2/
Attachment #8696517 - Attachment description: MozReview Request: Bug 1102924 - Follow-up: tidying in BrowserDatabaseHelper. → MozReview Request: Bug 1102924 - Follow-up: review comments.
Attachment #8696518 - Attachment description: MozReview Request: Bug 1102924 - Follow-up: muffle exceptions when ending transaction during migration of search history. → MozReview Request: Bug 1102924 - Follow-up: tidying in BrowserDatabaseHelper.
Comment on attachment 8696518 [details]
MozReview Request: Bug 1102924 - Follow-up: tidying in BrowserDatabaseHelper.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27347/diff/1-2/
Comment on attachment 8696519 [details]
MozReview Request: Bug 1102924 - Follow-up: muffle exceptions when ending transaction during migration of search history.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27349/diff/1-2/
Attachment #8696519 - Attachment description: MozReview Request: Bug 1102924 - Follow-up: use the Searches interface instead of directly accessing the ContentProvider. → MozReview Request: Bug 1102924 - Follow-up: muffle exceptions when ending transaction during migration of search history.
Comment on attachment 8696520 [details]
MozReview Request: Bug 1102924 - Follow-up: use the Searches interface instead of directly accessing the ContentProvider.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27351/diff/1-2/
Attachment #8696520 - Attachment description: MozReview Request: No bug - Implement extraction, parsing, and checking of sqlite version numbers. → MozReview Request: Bug 1102924 - Follow-up: use the Searches interface instead of directly accessing the ContentProvider.
No bug - Implement extraction, parsing, and checking of sqlite version numbers.

Some features, such as partial indices, require the cautious user to check for
support via SQLite version number.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: