Focusing out of <select> causes default attr to appear



Core Graveyard
13 years ago
2 years ago


(Reporter: Stephen Pride, Assigned: aaronr)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050114
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050114

Using an attribute as a reference in a <select> statement causes the default
attribute value to be elected when focus goes out of element.  I'll attach a
testcase for more clarity.

Reproducible: Always

Comment 1

13 years ago
Created attachment 172562 [details]
Bug that shows problem.

Should open with two selection boxes, both marked with "No" as the default. 
Select "Yes" in the first selection box and then set focus outside the first
one (by tabbing or clicking elsewhere).  The first selection box goes back to
the defualt attribute value of "No".


13 years ago
Ever confirmed: true

Comment 2

13 years ago
I debugged this last night.  This bug is related to how the node values are set
by nsXFormsSelectElement.  Most controls have gone to
nsXFormsUtils::GetNodeValue(mBoundNode) and
nsXFormsMDGEngine::SetNodeValue(mBoundNode) instead of doing it by hand.

Honestly, I don't know exactly what is going wrong, other than when the node
value is set now by ::WriteSelectedItems, it sets it just fine.  But then when
the value is about to be read back in nsXFormsSelectElement::Refresh(), the act
of ennumerating the child node list will cause the string that held the value in
the textnode to be freed and re-assigned to its original value.

When I change to use the new approach noted above, the problem is corrected.

I will post a patch today.

Comment 3

13 years ago
Created attachment 172587 [details] [diff] [review]
proposed fix

This patch fixes the problem using the methods I noted earlier in the bug.
Attachment #172587 - Flags: review?(smaug)
Summary: Focusin out of <select> causes default attr to appear → Focusing out of <select> causes default attr to appear

Comment 4

13 years ago
Comment on attachment 172587 [details] [diff] [review]
proposed fix

Isn't this breaking support for multiple selected values?
Attachment #172587 - Flags: review?(smaug) → review-

Comment 5

13 years ago
Actually, doesn't break the support...we currently don't work with muliselect
list boxes ->  Do you want
me to hold off with this patch until that is fixed?

Comment 6

13 years ago
rather fix Bug 278207, it will probably help with this one too.


13 years ago
Attachment #172562 - Attachment mime type: text/plain → application/xml+xhtml


13 years ago
Attachment #172562 - Attachment mime type: application/xml+xhtml → application/xhtml+xml

Comment 7

13 years ago
If I'm right, this was fixed in Bug 278207.
Last Resolved: 13 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.