Closed Bug 135002 Opened 22 years ago Closed 22 years ago

timing issues in the outliner content model.

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: skasinathan, Assigned: janv)

References

(
URL
)

Details

(Whiteboard: [ADT1] [m5+][hitlist] [ETA 04/22] [Needs a=] [landed on the trunk])

Attachments

(2 files, 1 obsolete file)

new patch
10.88 KB, patch
bryner
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
Patch that works for mozilla1.0.0 branch
11.61 KB, patch
janv
: review+
hewitt
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
Looks like there is some timing issues in the content model when we load the
data from the datasource. Hewitt saw this problem when we were debugging this in
the commercial tree.

Let me know if you folks need a test case to work on. Thanks!
Nominating. Commercial tree has seen this behaviour lately!
Keywords: nsbeta1
sure, a testcase whould be nice

What is the end user impact of this bug?  What are the prominent consumers of
the outliner using a datasource to populate themselves?  How rampant is this
problem?  Does it only occur on slower machines?  Thanks.
See bugscape bug 13003 for impact.
URL: http://bugscape.mcom.com/show_bug.cgi...
Severity: normal → major
varga, The one testcase I had in my mind works fine now. But it doesn't work in
one of the commercial module :(  Hewitt knows/saw the problem. Prolly he can
detail you. Thanks!
To answer samir's questions:

1. (as jelwell mentioned) see bugscape 13003 and 13191 for impact.
2. This problem occurs in our own product.
3. I have seen this problem in my 1 Ghz system. 
nsbeta1- per Nav triage team.  Both of the cited bugs are fixed, so if there is
still some serious problem, please describe it and the impact on users here.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1alpha
New info is that this also depends on
http://bugscape.mcom.com/show_bug.cgi?id=13670, which is nsbeta1+/ADT1.  Marking
nsbeta1+/ADT1.  Jan, do you have time to help on this?
Keywords: nsbeta1- → nsbeta1+
Whiteboard: ADT1
Bugscape 13003 is marked invalid because we choose to ship with something
similar but different one. 

http://bugscape.netscape.com/show_bug.cgi?id=13670 deals with the new one.
URL: http://bugscape.mcom.com/show_bug.cgi... → http://bugscape.netscape.com/show_bug...
Sure, could someone send me a private copy of the bugscape bug ?
A testcase demonstrating this problem would be great.

This is a pretty important bug [m5+], shouldn't we try and get it into 1.0?
Whiteboard: ADT1 → [ADT1] [m5+]
Target Milestone: mozilla1.1alpha → mozilla1.0
adding metabug blockage
Blocks: 136384
I don't really understand what is going on here, either.  I can only describe
the symptoms.  In the buddy list, sometimes certain rows will get appended at
the wrong level and row index in the view.  The buddy list uses the content
view, and is generated by an rdf template.

reassigning to Jan since he is the tree content view dude
Assignee: hewitt → varga
working on a testcase
Taking this on my hitlist.
Whiteboard: [ADT1] [m5+] → [ADT1] [m5+][hitlist]
Depends on: 137890
Status: NEW → ASSIGNED
Whiteboard: [ADT1] [m5+][hitlist] → [ADT1] [m5+][hitlist] [ETA 04/22]
Attached patch new patch — — Splinter Review 
- fixed AttributeChanged() to only care about its own children
Attachment #79868 - Attachment is obsolete: true
Comment on attachment 79949 [details] [diff] [review]
new patch

r=bryner
Attachment #79949 - Flags: review+
hewitt, can you sr this bug? Thanks.
Comment on attachment 79949 [details] [diff] [review]
new patch

sr=hewitt
Attachment #79949 - Flags: superreview+
The SR is here, let's tryn and get this one in asap. adt1.0.0.
Keywords: adt1.0.0, approval
Whiteboard: [ADT1] [m5+][hitlist] [ETA 04/22] → [ADT1] [m5+][hitlist] [ETA 04/22] [Needs a=]
Whiteboard: [ADT1] [m5+][hitlist] [ETA 04/22] [Needs a=] → [ADT1] [m5+][hitlist] [ETA 04/22] [Needs a=] [landed on the trunk]
I'm asking some people to test this out in mailnews but they are saying that the
patch fails  to build on the branch.  Could you provide and updated patch?
It was actually a problem applying the patch, not building with it.
I failed too, in a way I am not comfortable manually fixing (I tried, but seems
like there was enough change between the branch and the tree this patch was
applied to that I cannot be sure). Could you apply an updated patch for the
branch so we can do some testing tonight?
Ok, I did this carefully by hand and feel good about it -- that patch I will be
posting should be easily applied to the current branch. There was one chunk of
code that appears to have been new to Jan's tree that is not in the branch. That
was what was causing the patch to fail. Jan, please look at the patch and verify
this is what we need for the branch. 
This patch can be used for testing. Ultimately, Jan Varga should validate the
patch before it lands.
Comment on attachment 81258 [details] [diff] [review]
Patch that works for mozilla1.0.0 branch

Yeah, this looks good.
Actually, it was patch for optgroups which made this not apply on the 1.0
branch
Attachment #81258 - Flags: review+
r=varga
yeah, I had problems with the when I originally tried. I ended up manually doing
myseld! 
This is fixed in the trunk and the dependent bugscape bug
(http://bugscape.netscape.com/show_bug.cgi?id=13670) is verified. Marking this
as fixed so that adt can approve this to checkin to the branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
adding adt1.0.0+.  Please check this into the branch as soon as possible and add
the fixed1.0.0 keyword after getting drivers approval.
Keywords: adt1.0.0 → adt1.0.0+
landed on the branch
Keywords: fixed1.0.0
No driver gave a=.  This should not have been checked into the branch.  Also,
the branch patch has no sr marked.  Please justify leaving this patch in to
drivers@mozilla.org, and also please obtain an sr= for the branch patch.

rjesup@wgate.com for drivers.
I'm confused with this adt=, a= and whatever stuff
This patch is almost identical to previous one. I got first sr= after 5 days.
This patch was tested by Navigator and Mailnews QA and I was requested to check
in  to the branch.
So now I'm not sure what I was supposed to do actually.
In case that this is problem, back it out

I think this was just an honest oversight, made more likely by ADT time pressure
(deadline of 3AM!).  If there are no known problems with the checkin, could we
possibly just get SR= on the changes from the original patch, and a= from
drivers?  That would be a lot more efficient than backing out, going through the
correct Process, and checking in again.
That patch was a part of the binary that was sent around for testing. So, it is
very likely good, it was just a matter of manually applying the patch because of
some unrelated differences between trunk and branch. My thought is the sr= from
the trunk patch is sufficient for the branch one (in fact, the reason I placed
that patch here was just to make it easy on the person who had to checkin the
patch to the branch, not because it was anything significantly different).
Comment on attachment 81258 [details] [diff] [review]
Patch that works for mozilla1.0.0 branch

sr=hewitt
Attachment #81258 - Flags: superreview+
Comment on attachment 81258 [details] [diff] [review]
Patch that works for mozilla1.0.0 branch

retroactive a=rjesup@wgate.com for drivers.  Thanks for clearing up what
happened.
Attachment #81258 - Flags: approval+
HUGE thanks to Varga for fixing this bug and also to everyone else involved in
this bug!!

The dependent bugscape bug is verified in branch and trunk. Marking this as
verified.
Status: RESOLVED → VERIFIED
Just to be sure we are clear of this problem some testing on slow (e.g., 200Mhz)
machines should be done in the coming weeks. I ran into some problems today with
a newer build and it is not clear to me we are completely out of the woods yet.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: