User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11) Gecko/20060111 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:22.214.171.124) Gecko/20060111 Firefox/126.96.36.199 1) added a builder listener to catch didRebuild 2) did an assign of new RDF sources to tree.datasources field: wTree.datasources = structure + " " + testblock; 3) when didRebuild fires, tree.view is still null and remains null for upto 500ms on a 3GHz machine. Reproducible: Always Steps to Reproduce: 1. add a builder listener to catch didRebuild 2. do an assign of new RDF sources to tree.datasources field 3. when didRebuild fires, tree.view is still null Actual Results: tree.view is null for upto 500ms AFTER didRebuild fires Expected Results: tree.view should NOT be null afer didRebuild fires work around is to access tree.view via setTimeout("code", 500); yuck! :( test case to follow - as soon as I have stripped out customer's info
Component: Extension/Theme Manager → XUL Widgets
Product: Firefox → Toolkit
Version: unspecified → 1.8 Branch
13 years ago
QA Contact: extension.manager → xul.widgets
I've just now repeated this test with a large RDF structure (8000 rows) and the delay is now on the order of 600ms. Additionally - any attempt to open all the leaves of the tree immediately after 600ms on this large RDF file leaves the last 200 rows or so, still closed... looks like they were unavailable to tree.view.rowCount that quickly This is just WRONG - if didRebuild fires, then the tree should be ready to go. test case with large and small RDF files to follow
Severity: normal → major
This problem is the same with small RDF file ( build by Apache / php script) if you add on alertbox on the didRebuild function, the real rebuild works fine. you can see this problem in (french...) here http://xulfr.org/forums/read.php?1,7054 the didRebuild don't fire on the good time....
Not blocking without: - indication of whether or not this is a regression - indication of impact to general user / website author - confirmation or testcase If you get those three things, please feel free to renominate.
Flags: blocking1.9.1? → blocking1.9.1-
You need to log in before you can comment on or make changes to this bug.