[DOGFOOD] persist="open" in folder pane causes child folders to appear above parents

RESOLVED FIXED in M11

Status

()

Core
XUL
P3
normal
RESOLVED FIXED
19 years ago
10 years ago

People

(Reporter: Alec Flett, Assigned: Chris Waterson)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix ready)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
I tired putting persist="open" in the folder pane XUL
(mailnews/base/resources/content/folderPane.xul) in order to use the new
persistance stuff to remember which folders were open... I got the idea from
rjc's similar checkin for bookmarks.

When I added this attribute, opened some folders and then restarted messenger,
all "open" folders had their children ABOVE the opened parent rather than below.

Updated

19 years ago
Assignee: rjc → hyatt

Comment 1

19 years ago
This is a tree bug... so reassigning to David, Mr. "I love trees!"

Updated

19 years ago
Target Milestone: M14

Comment 2

19 years ago
targetting m14
(Reporter)

Updated

19 years ago
Blocks: 13931
(Reporter)

Comment 3

19 years ago
this also happens when you add open="true" to your rdf template for trees.

Updated

19 years ago
Assignee: hyatt → waterson

Comment 4

19 years ago
reassigning to waterson, hyatt will sit with you on this.

Updated

19 years ago
Target Milestone: M14 → M11

Comment 5

19 years ago
does anyone have any idea where I'd look to try to fix this?  i'm trying to work
on threads in the thread pane and I want them to be open and of course, if I use
open="true" they all open upwards.  I'm changing the milestone to M11, because I
need it.  I'm willing to look into it, but I need some hints if you have them.
(Assignee)

Comment 6

19 years ago
hyatt believes that this is caused because the RDF generic builder is creating
the <treerow> _after_ it creates and popuplates the <treechildren>; i.e., we
get a content model like...

<tree>
  <treechildren>
    <treeitem>
      <treechildren>
        ...
      </treechildren>
      <treerow><treecell/></treerow>
    </treeitem>
  </treechildren>
</tree>

We should look at the DOM that gets generated and verify that this is the
case...
(Reporter)

Comment 7

19 years ago
I've been looking into this actually, and this is exactly what happens, I've
verified this by looking at the DOM that's created. I haven't tracked it down in
the code yet, but I'm quite certain it's the generic builder.
(Reporter)

Comment 8

19 years ago
in fact, look at FindInsertionPoint() - it special cases for TreeItems and says
to insert the element at the first <treechildren> - still trying to figure out
if that means After, Before, or Inside this element.
(Assignee)

Comment 9

19 years ago
I think that may be a red herring. I'm suspicious that it has something to do
with how BuildContentFromTemplate() and EnsureElementHasGenericChild() are
interacting...
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 10

19 years ago
bulldozer to M12
(Assignee)

Updated

19 years ago
Target Milestone: M12 → M11
(Assignee)

Comment 11

19 years ago
pull back to M11. i have a fix for this. attaching patch. can somebody review?
thanks!
(Assignee)

Updated

19 years ago
Summary: persist="open" in folder pane causes child folders to appear above parents → [DOGFOOD] persist="open" in folder pane causes child folders to appear above parents
Whiteboard: fix ready
(Assignee)

Comment 12

19 years ago
Created attachment 2565 [details] [diff] [review]
proposed fix

Comment 13

19 years ago
I'm not sure I'm the right person to be reviewing this but it looks like you are
now creating the row before creating it's children instead of the opposite which
seems to be a good thing in which case I'll say it looks good to me.

Just out of curiosity why did this only happen when "open" was specified in the
template?
I haven't verified Alec's original case for the bug, but I tested it out on the
thread example I gave earlier and that works correctly now.
(Assignee)

Comment 14

19 years ago
RDF-generated content pays special attention to the "open" attribute, and
pretends that no content exists beneath a node that isn't "open". So, when
"open" was set, it would recurse down to create children during frame
construction, rather than being triggered -later- by an event handler (which'd
call RebuildWidgetItem(), which'd happen to get things right).
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
*** Bug 17128 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Comment 17

18 years ago
Massive QA Contact update.
QA Contact: ckritzer → jrgm

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.