Closed Bug 134195 Opened 22 years ago Closed 22 years ago

Trees do not respond (preferences, mail, history, directory/folder listings, bookmarks, download manager, chatzilla, address book, page info, form manager, composer property editor, etc.)

Categories

(Core :: XUL, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: fredbezies, Assigned: hewitt)

References

Details

(Keywords: regression, Whiteboard: [adt1])

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020328
BuildID:    2002032903

When preferences panel is open, the only usable /things/ are OK, Cancel and Help
buttons :-(

List is completely frozen :-(

Had to go back to 2002032803 build.

Reproducible: Always
Steps to Reproduce:
1.Open preference panel
2.try clicking on left side list.


Actual Results:  Nothing happens !

Expected Results:  List must be modified in order to use preferences !
Yep, I was just about to report this.
Confirmed 2002032903/WinXP
Status: UNCONFIRMED → NEW
Ever confirmed: true
On Win2k 2002032903 none of my tree controls respond. Not prefs, not mail. 
Confirmed 2002032908/Linux
*** Bug 134212 has been marked as a duplicate of this bug. ***
It seems that 29th march builds are completely broken !

<a little laugh in order to ease the pain ?>

Who will get his ass spanked ? ;-)

</a little laugh in order to ease the pain ?>

By the way, it is the worst bug I ever met ! :-(
this is actually happening to any folder/list type access...not just in 
preferences.  

folders in bookmarks sidebar tabs are inaccessable.  
folders in Tasks | Tools | History are inaccessable.

probably many more places?

note: this is happening on linux also. It is not, however, happening on either 
mac os9 or mac osx builds from this morning.
OS: Windows XP → All
keywords added
changing component and summary
Assignee: ben → hewitt
Component: Preferences → XP Toolkit/Widgets: Trees
Keywords: mozilla1.0, nsbeta1
QA Contact: sairuh → shrir
Summary: Preferences panel is frozen on left side. → Trees do not respond (preferences, mail, history, directory listings, etc.)
*** Bug 134243 has been marked as a duplicate of this bug. ***
We get a whole bunch of these in the JS Console for each click on a tree
(sometimes tree.xml is a different file like bookmarks.xml) but its the same
problem.  

Error: uncaught exception: [Exception... "Could not convert JavaScript argument 
(NULL value cannot be used for a C++ reference type) arg 0 
[nsISupports.QueryInterface]"  nsresult: "0x8057000b 
(NS_ERROR_XPC_BAD_CONVERT_JS_NULL_REF)"  location: "JS frame :: 
chrome://global/content/bindings/tree.xml#tree.treeBoxObject (getter) :: onget 
:: line 0"  data: no]

Replacing the XML files with ones from yesterday just breaks everything.
Download manager won't respond either.
Is that better?  Seriously, its anything having trees, but maybe that will catch
some people before they create more dupes.
Summary: Trees do not respond (preferences, mail, history, directory listings, etc.) → Trees do not respond (preferences, mail, history, directory/folder listings, bookmarks, download manager, chatzilla, address book, page info, form manager, composer property editor, etc.)
wfm with a ~1h old cvs build on win2k
this is working on linux respin 2002-03-29-10-trunk
Fixed by changes to xpinstall/packager/packages-* checked in a few hours ago
(and in the respin).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 134197 has been marked as a duplicate of this bug. ***
QA, please Verifiy bug 134197 when verifying this bug to ensure that they are
indeed dupes (and the fix fixes both).
This bug is /dead/.

Let's hope I will be for ever :-)

Using : 200203290316 nightly build.

Thanks a lot :-)
Verified fixed with a CVS build from 2002-03-30-10 on Linux.
Status: RESOLVED → VERIFIED
verified with commercial trunk builds:

windows 2002-04-01-06-trunk
linux 2002-04-01-06-trunk
*** Bug 134879 has been marked as a duplicate of this bug. ***
*** Bug 138865 has been marked as a duplicate of this bug. ***
*** Bug 138361 has been marked as a duplicate of this bug. ***
*** Bug 138912 has been marked as a duplicate of this bug. ***
*** Bug 139158 has been marked as a duplicate of this bug. ***
*** Bug 139120 has been marked as a duplicate of this bug. ***
How is this "fixed" -- look at all the dupes! This is happening to tons of
people who upgrade from 0.9.9 to 1.0rc1 (and presumably any commercial release
that might be based on 1.0). Did this fix leave cruft around in the chrome
registry of profile files? Hard to even know what the fix was since there's no
patch or link to what was done to fix this. Wishful thinking?
Status: VERIFIED → REOPENED
Keywords: nsbeta1nsbeta1+
Resolution: FIXED → ---
Whiteboard: [adt1]
There were two separate parts to the fix:
 * one was making the packaging changes that hewitt missed (this fixed the
release builds) to add his new xul_tree.xpt file to the packaged build
 * one was fixing a build problem in the dependency system that caused xpt files
not to be regenerated properly when an IDL file was removed from a directory

Perhaps there's a *third* bug relating to failing to remove old xpt information
when we install new xpt files in the installer?
Perhaps we either need to:
 * install zero-size xpt files for the removed xul_outliner.xpt
 * give the interfaces whose names have changed (but semantics have not) new IIDs

I suspect the underlying problem here is actually slightly different from the
first two bugs, since it probably results from having layout_xul_outliner.xpt
still around.  Problem (1) in my previous comment was the result of NOT having
layout_xul_tree.xpt, and problem (2) in my previous comment was the result of
having stale data in Layout_xul.xpt.
In any case, this shouldn't have been reopened to smoketest blocker status.  (Is
there any evidence that *any* of the duplicates were for reasons other than
unzipping a new build directly on top of an old one?)
Severity: blocker → critical
Keywords: smoketest
Definitely not fixed as of m1.0rc1 and definitely not related to "unzipping over
an old installation".  I just ran the installer to update from 0.9.9 and ran
into this bug.

--
Trever Furnish, t at wondious dot com
Definitely still there in build 2002041711 (1.0 RC1).  I installed on three computers, all 
running Windows 2000 Pro, using the installer to install over 0.9.9.  The problem showed up on two 
computers but not on the third.  It's a killer because email is not usable ... I can get messages, but 
I can't expand the folder tree to see them!

A complete uninstall and reinstall fixed it on one 
computer.  I haven't tried that on the second computer with the problem yet.  This is not a 
particularly desirable workaround, because I lost all the old email (I copied the files, 
uninstalled, installed, created the accounts, and copied the files back ... Mozilla wouldn't 
open the inbox, just displayed an hourglass cursor forever).
*** Bug 139991 has been marked as a duplicate of this bug. ***
*** Bug 140026 has been marked as a duplicate of this bug. ***
*** Bug 138414 has been marked as a duplicate of this bug. ***
Intresting effect: When I'm going to update 0.9.9 to 1.0RC1 i've problems with
this bug, but after deinstalling Mozilla, rebooting Windows and reinstall RC1
everything works fine.

isn't bug 135017 a dup of this?
I believe David is right - the old xul_outliner.xpt is still around in these
situations, and the IIDs are conflicting with the IIDs in xul_tree.xpt.  This
patch just gives new IIDs to the affected interfaces.
Comment on attachment 81182 [details] [diff] [review]
patch to change iids

r=dbaron.  (I'm assuming you generated the uuids appropriately, with uuidgen or
/query botbot. :-)
Attachment #81182 - Flags: review+
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Comment on attachment 81182 [details] [diff] [review]
patch to change iids

jag sez sr=jag
Attachment #81182 - Flags: superreview+
Comment on attachment 81182 [details] [diff] [review]
patch to change iids

a=rjesup@wgate.com for drivers.  Please check into both trunk and branch.
Attachment #81182 - Flags: approval+
fixed
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
*** Bug 141473 has been marked as a duplicate of this bug. ***
mailnews tree are frozen in 1st may nightly win32 build :-/

Go back to 30th april nightly build.
Frederic, delete component.reg. It fixed the problem for me with the 1st may build
Keywords: fixed1.0.0
*** Bug 138365 has been marked as a duplicate of this bug. ***
I certainly wouldn't call this fixed.

I've just downloaded the latest nightly build (05/08/2002) and the latest 1.0.0
build (from nightly/latest-1.0.0/ -- 05/08/2002) and both of them still exhibit
this bug. I downloaded the 04/30/2002 build and the trees work fine.

If this helps, i'm running Win2k SP2+. I did not attempt to completely uninstall
Mozilla before installing the new builds.
As of 5/13/2002 i've seen no response to my (the last) comment on this bug. And,
the bug is still not fixed. I also tried deleting component.reg as suggested in
another comment, but this had no effect.

I would not consider this bug fixed unless a user can install the software and
have it work without having to delete files or apply patches.

Please mark this bug as unresolved and take appropriate action to correct.

after doing a complete uninstall (plus manually cleaning any vestigial files or
directories, including user profile) and installing (05/14/2002 build of) RC2,
this bug appears to be fixed.
verified..builds have been working fine.
Status: RESOLVED → VERIFIED
I have had this problem since I upgraded to RC1. When RC2 was out I tried 
again - still there, RC3 - still there. I did not want to lose my emails so 
did not uninstall/reinstall.

I have solved the problem as follows:
1. Install RC3 (now I could not access any trees)
2. Delete all *.X?? files that were older than the RC3 date (23 May)
3. Install RC3 (all trees working now)

I then did the search again and found no *.X?? files older than the RC3 date.
 
Maybe the problem is the installer not overwriting certain files?

Anyway I hope this helps anybody else still suffering with this bug.
*** Bug 138857 has been marked as a duplicate of this bug. ***
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

Created:
Updated:
Size: