Handle dynamic insertions in repeat subtree

RESOLVED WONTFIX

Status

Core Graveyard
XForms
P5
enhancement
RESOLVED WONTFIX
13 years ago
a year ago

People

(Reporter: Allan Beaufour, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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

13 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

13 years ago
Blocks: 264329
(Reporter)

Comment 1

13 years ago
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
(Reporter)

Comment 2

12 years ago
Alex, do you have a comment on the assertion message?
(Reporter)

Comment 3

12 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

12 years ago
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

12 years ago
(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

12 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

12 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....

Updated

12 years ago
Blocks: 323593

Updated

12 years ago
Blocks: 326372

Updated

12 years ago
Blocks: 326373
(Reporter)

Updated

12 years ago
Severity: normal → enhancement
Priority: -- → P5
(Reporter)

Updated

11 years ago
No longer blocks: 326372
(Reporter)

Updated

10 years ago
Assignee: allan → xforms
Status: ASSIGNED → NEW
RIP xforms
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.