Closed
Bug 273706
Opened 20 years ago
Closed 9 years ago
Handle dynamic insertions in repeat subtree
Categories
(Core Graveyard :: XForms, enhancement, P5)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: allan, Unassigned)
References
Details
Attachments
(2 files)
1.55 KB,
application/xhtml+xml
|
Details | |
12.60 KB,
patch
|
Details | Diff | Splinter Review |
smaug commented on bug 269132:
"How do you handle the case where someone is modifying the subtree of the
repeat element dynamically? Shouldn't you listen DOMSubtreeModified and
on event call Refresh() or something like that."
He's probably right :)
Reporter | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 1•20 years ago
|
||
Testcase.
XTF is not too happy about it:
###!!! ASSERTION: element not implementing nsIContent!?: 'content', file
nsXTFFrameUtils.cpp, line 51
Break: at file nsXTFFrameUtils.cpp, line 51
WARNING: NS_ENSURE_TRUE(aContent) failed, file nsFrameManager.cpp, line 372
Reporter | ||
Comment 2•20 years ago
|
||
Alex, do you have a comment on the assertion message?
Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #2)
> Alex, do you have a comment on the assertion message?
Olli had a clue for it. We returned a nsnull insertion point...
Reporter | ||
Comment 4•20 years ago
|
||
Here's a rough patch, should work for non-nested repeats, but I have not tested
it much.
(In reply to comment #4)
> Created an attachment (id=180795) [edit]
> Rough patch
>
Does this work also when you modify something, which is not a
child of the repeat element, but further descendant?
Reporter | ||
Comment 6•20 years ago
|
||
(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=180795) [edit] [edit]
> > Rough patch
>
> Does this work also when you modify something, which is not a
> child of the repeat element, but further descendant?
Nope. I should possibly have mentioned that *ahem*. So admittedly, it's a sorry
excuse for a fix, but then we're back at the mutation events, aren't we? And
"somebody" keeps telling me to avoid using that for now ... or something :)
Reporter | ||
Comment 7•20 years ago
|
||
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Created an attachment (id=180795) [edit] [edit] [edit]
> > > Rough patch
> >
> > Does this work also when you modify something, which is not a
> > child of the repeat element, but further descendant?
>
> Nope. I should possibly have mentioned that *ahem*. So admittedly, it's a sorry
> excuse for a fix, but then we're back at the mutation events, aren't we? And
> "somebody" keeps telling me to avoid using that for now ... or something :)
I've looked a bit into the mutation events, and they are rather expensive aren't
they? I'm tempted to let us support what I have here, but WONTFIX anything more
than that... what do you say? Dynamics (in general) is not a must....
Reporter | ||
Updated•19 years ago
|
Severity: normal → enhancement
Priority: -- → P5
Reporter | ||
Updated•17 years ago
|
Assignee: allan → xforms
Status: ASSIGNED → NEW
Comment 8•9 years ago
|
||
RIP xforms
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•