Last Comment Bug 273706 - Handle dynamic insertions in repeat subtree
: Handle dynamic insertions in repeat subtree
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
P5 enhancement with 1 vote (vote)
: ---
Assigned To: xforms
: Stephen Pride
:
Mentors:
Depends on:
Blocks: 264329 323593 326373
  Show dependency treegraph
 
Reported: 2004-12-08 04:11 PST by Allan Beaufour
Modified: 2016-07-15 14:46 PDT (History)
6 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Testcase (1.55 KB, application/xhtml+xml)
2005-02-21 06:21 PST, Allan Beaufour
no flags Details
Rough patch (12.60 KB, patch)
2005-04-15 07:04 PDT, Allan Beaufour
no flags Details | Diff | Splinter Review

Description User image Allan Beaufour 2004-12-08 04:11:08 PST
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 :)
Comment 1 User image Allan Beaufour 2005-02-21 06:21:27 PST
Created attachment 175002 [details]
Testcase

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
Comment 2 User image Allan Beaufour 2005-04-15 02:59:51 PDT
Alex, do you have a comment on the assertion message?
Comment 3 User image Allan Beaufour 2005-04-15 03:10:55 PDT
(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...
Comment 4 User image Allan Beaufour 2005-04-15 07:04:08 PDT
Created attachment 180795 [details] [diff] [review]
Rough patch

Here's a rough patch, should work for non-nested repeats, but I have not tested
it much.
Comment 5 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2005-04-15 07:20:09 PDT
(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?

Comment 6 User image Allan Beaufour 2005-04-18 04:15:24 PDT
(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 :)
Comment 7 User image Allan Beaufour 2005-04-29 05:44:13 PDT
(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....
Comment 8 User image David Bolter [:davidb] 2016-02-04 12:21:47 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.