Closed Bug 10208 Opened 25 years ago Closed 24 years ago

Need to update empty attribute when items added/removed

Categories

(Core Graveyard :: RDF, defect, P2)

Product:
Core Graveyard
Component:
RDF
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: waterson)

References

Details

Attachments

(4 files)

diff for updating empty attribute on add
3.04 KB, patch
Details | Diff | Splinter Review
10208.xul; save in $(DIST)/bin/chrome/test/content/default
2.45 KB, text/plain
Details
10208.css; save in $(DIST)/bin/chrome/test/content/default/
91 bytes, text/plain
Details
proposed fix
16.65 KB, patch
Details | Diff | Splinter Review 
Currently twisties don't work correctly when you add a new folder to the
Messenger 3 pane.  I'm assuming it's because the "empty" attrbute isn't being
updated.  I haven't tried deleting a folder to see if the twisty disappears, but
it should be updated when and item is added or removed.
OS: Windows NT → All
Hardware: PC → All
I assume this is for all platforms.
Scott, is this working now?
No, this isn't working.
I'll look at the changes that Chris checked in last night and then try and
figure out what case still isn't being handled.
I think scottip was seeing a related bug where he'd change an attribute on a
message (e.g., from "unread" to "read") and the style rules wouldn't reflow.
I'd bet it's more closely related to that...

Scott, are you still seeing that other bug?
Yes.  But double clicking on a folder to open/close it doesn't make it show up
either.  Wouldn't that force it to resize and draw correctly?
Status: NEW → ASSIGNED
Assignee: rjc → putterman
Status: ASSIGNED → NEW
The code to set/remove the "empty" attribute which Chris wrote looks correct to
me.

Double-clicking on a folder DOES make it show up (at least, in my Mac build from
today: Aug 10th).  I'm guessing that Chris/Scottip are right: style reflow bug.
Scott, might want to point this bug at one of the CSS guys and see if they have
any idea.
Assignee: putterman → hyatt
OK.  I'll start off with hyatt to see if he has any ideas why the tree isn't
picking this up.
Status: NEW → ASSIGNED
Target Milestone: M10
Sounds like a duplicate of the "titled buttons don't reflect changes" bug that I
already have.  That's what's going on, right?  The titled button isn't picking
up the change?
It sounds like that could be it.  The problem which caused me to file the titled
button bug no longer occurs, but this might be a different manifestation of it.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 8467 ***
Blocks: 10804
*** Bug 16915 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
We are still seeing this.  Perhaps it wasn't a dup?
Resolution: DUPLICATE → ---
Target Milestone: M10
clearing resolution.
clearing M10 target milestone since this is reopened and M10 has passed.  Pls
assign a new target milestone.
*** Bug 18675 has been marked as a duplicate of this bug. ***
I have a fix for making the added case work.  It's the attached patch.
Basically we never updated the empty attribute it the content wasn't generated
which is the case when it's closed.

I'm not sure what to do about the deleted case.  In this case the code updates
the empty attribute if the num children are 0.  I'm getting that this value is 2
and I think the reason why is that treeitem has children of type treerow and
treechildren.  We really want to know if the numChildren of the treechildren is
0.  I'm not sure of the best way to do this in a generic way.

Can someone review the adding case?  This will really help with new folders and
new messages in threads.
this looks good scott: this in OnAssert(), right? should we do the same thing
in OnUnassert() and OnChange()?
This is OnAssert.  I didn't know about OnChange.  OnUnassert has the problem I
mentioned with the number of children.  I'm not sure how to solve that.
ok, well go ahead and check in what you've done, and you can reassign the bug
to me and i'll try to figure something out.
Assignee: hyatt → waterson
Status: REOPENED → NEW
i checked in the fix for adding a new item.  reassigning to waterson as
suggested.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M13
QA Contact: phillip → paulmac
phillip gone, changing qa contact
*** Bug 21292 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M14
Release Notes for M13
Target Milestone: M14 → M15
Target Milestone: M15 → M16
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF 
bugs
QA Contact: paulmac → tever
Add a test case; save attached .xul and .css files in directory 
$(DIST)/bin/chrome/test/content/default/. To reproduce:

1. Run "mozilla -chrome chrome://test/content/10208.xul". You should see a 
small window with two buttons and a tree widget.

2. Open the single item in the tree widget. Note that the "container" item is 
bold.

3. Click the "Remove" button twice to remove both elements from the tree 
widget. The container item should change from bold to plain font.

4. Click the "Add" button to add an element to the container. The container 
item should turn from plain font back to bold.
Attached patch proposed fix — — Splinter Review 

    
    

    
  
Ok, I've attached a proposed fix. If y'all want to try it, I'd be much obliged. 
I'm going to profile the new code before checking in, just to make sure I 
didn't regress performance.

    
    

    
  
I can't seem to make patch take this.  Can you send me a patch with diff -c instead?


    
    

    
  
With the file you sent me, this wasn't fixed.  I added a new folder and no
twisty showed up.  I can see the notification going through to RDF so I think
things are ok on our end, but I could be wrong about that.


    
    

    
  
I tested this with "new subfolder" and with "newsgroup subscribe", and it 
worked in both cases. I'm checking this in tonight, marking fixed, and we'll 
see what QA finds in the morning...

    
    

    
  
oops, fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
you are right.  I must not have downloaded the patch correctly.

    
    

    
  
verified:
WinNT 2000070508
Status: RESOLVED → VERIFIED

    
  
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: