Closed Bug 377874 Opened 18 years ago Closed 18 years ago

repeat-attrs on table causing complex content binding error

Categories

(Core Graveyard :: XForms, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sspeiche, Assigned: aaronr)

References

()

Details

(Keywords: fixed1.8.0.12, fixed1.8.1.4)

Attachments

(3 files, 3 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070416 Minefield/3.0a4pre Build Identifier: This fails non-normative W3C test suite case 9.3.2.a Reproducible: Always
Attached file test case
problem here is the initial output from the document doesn't live under a range since the range is introduced via anonymous content. So when we run it through UpdateRepeatState, it is coming back as eType_NotApplicable. Will have to change the logic there to look for xforms repeat attrs. Well, at least the attr(s) that introduce repeats into anonymous content.
Assignee: xforms → aaronr
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch patch (obsolete) — Splinter Review
made fix using check for repeat attrs, so no more error message popping up.
Attachment #262051 - Flags: review?(Olli.Pettay)
Comment on attachment 262051 [details] [diff] [review] patch removing request. I screwed something up.
Attachment #262051 - Flags: review?(Olli.Pettay)
(In reply to comment #4) > (From update of attachment 262051 [details] [diff] [review]) > removing request. I screwed something up. > Crap. If we detect repeat attrs on the parent, we need to know if the current element is a repeat or not. If it is then it is the anonymous repeat that is contained by the element with repeat attrs and we need to give it eType_NotApplicable. Otherwise it'll be eType_Template. However, at the stub element level we don't have access to mElement. So looks like we are going to have to store mElement in stub element instead of in control stub, action, etc. It is more overhead for every xforms element now, but not as much as having to move the repeat state and functions out of stub element.
Attached patch patch2 (obsolete) — Splinter Review
Overrode UpdateRepeatState on repeat to figure out if it is an attr based repeat. Beats moving mElement into stub element.
Attachment #262051 - Attachment is obsolete: true
Attachment #262094 - Flags: review?(Olli.Pettay)
Attached patch patch for 1.8 and 1.8.0 branches (obsolete) — Splinter Review
Attachment #262094 - Flags: review?(surkov.alexander)
oops, forgot I had trace in the tree from another bug.
Attachment #262096 - Attachment is obsolete: true
Comment on attachment 262094 [details] [diff] [review] patch2 >+ /** >+ * Override of nsXFormsStubElement's function. Needed to properly handle >+ * the case where the repeat is generated by anonymous content. nit: nice if you would mention here about attr-based repeat binding because it's not clear about what anon content you said. >+ if (NS_SUCCEEDED(rv)) >+ // if repeat is attribute based, it won't go through the normal >+ // attribute change processing, so should set the mIsAttributeBased >+ // variable here >+ mIsAttributeBased = isAttributeBased; >+ if (isAttributeBased) { >+ repeatState = eType_NotApplicable; >+ SetRepeatState(repeatState); >+ return repeatState; >+ } >+ } nit: either line up properly if (isAttributeBased) or add brackets for top if statement.
Attachment #262094 - Flags: review?(surkov.alexander) → review+
Attachment #262094 - Flags: review?(Olli.Pettay) → review+
fixes surkov's nits, ready for checkin once the tree goes green
Attachment #262094 - Attachment is obsolete: true
checked into trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
checked into 1.8 and 1.8.0 branches
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: