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)
Core
DOM: Core & HTML
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"
Assignee | ||
Comment 1•25 years ago
|
||
Oops, the Bug Helper gave this to V not me. :)
Assignee: vidur → pollmann
Whiteboard: Fix in hand.
Target Milestone: M14
Assignee | ||
Comment 2•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: Fix in hand. → Fix in hand. (Reviewed, ready to check in)
Assignee | ||
Comment 3•25 years ago
|
||
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
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
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)
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
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.
Assignee | ||
Comment 8•24 years ago
|
||
Thanks drbrain - reopening bug per your comments.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Whiteboard: Fix in hand. (Reviewed, ready to check in)
Target Milestone: M14 → M15
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
My mistake, textarea.value is working. Sorry for the spam
Assignee | ||
Comment 13•24 years ago
|
||
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
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
this sounds fairly serious. eric, any chance you could look at this and see if it's a quick fix?
Comment 18•24 years ago
|
||
Sorry for mentionning Moz 0.9, I meant of course Moz 0.7 (build 2001010901).
Assignee | ||
Comment 19•24 years ago
|
||
Popping back off the future list. Yep, this is potentially bad...
Target Milestone: Future → mozilla0.9
Assignee | ||
Comment 20•24 years ago
|
||
> 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 ago → 24 years ago
Resolution: --- → FIXED
Comment 21•24 years ago
|
||
we need to document this! For once I think the specs are badly designed, this is totally non intuitive to the user
Comment 22•24 years ago
|
||
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?
Assignee | ||
Comment 23•24 years ago
|
||
> 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!
Assignee | ||
Comment 24•24 years ago
|
||
*** Bug 67560 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Component: DOM Level 1 → DOM HTML
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
Comment 29•8 years ago
|
||
Bug 1102924 - Sync search history into search history provider
Comment 30•8 years ago
|
||
Bug 1102924 - Follow-up: fix tests.
Comment 31•8 years ago
|
||
Bug 1102924 - Follow-up: review comments.
Comment 32•8 years ago
|
||
Bug 1102924 - Follow-up: tidying in BrowserDatabaseHelper.
Comment 33•8 years ago
|
||
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.
Comment 34•8 years ago
|
||
Bug 1102924 - Follow-up: use the Searches interface instead of directly accessing the ContentProvider.
Comment 35•8 years ago
|
||
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 36•8 years ago
|
||
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 37•8 years ago
|
||
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 38•8 years ago
|
||
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.
Updated•8 years ago
|
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 39•8 years ago
|
||
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 40•8 years ago
|
||
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 41•8 years ago
|
||
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.
Comment 42•8 years ago
|
||
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 43•8 years ago
|
||
Bug 1102924 - Add missing Robocop annotations.
You need to log in
before you can comment on or make changes to this bug.
Description
•