177870 - Freezes after dropping menu

Status: VERIFIED WORKSFORME

(Firefox :: Menus, defect)

Description

[Roger Bivand]

Phoenix-0.4 freezes and has to be kill -9'ed when say Tools or Bookmarks menus
are dropped down. A menu item (any?, like manage bookmarks, preferences - those
that spawn a window) can be clicked, goes blue, and the program freezes. Have
reverted to 0.3. RH7.2 platform. This on a machine on a radio link (3km) that
has chunky gaps in transmission, bandwidth is high, but comes in blocks,
depending on who else is on the antenna node - could this interfere with an
event loop? Will try on a desk machine with less chunky network conditions.

Comment 1

[André Dahlqvist]

I have to ask you the standard questions: did you install Phoenix to a clean
directory (not over a previous installation) and did you remove your ~/phoenix
before trying the new version? Phoenix is changing a lot and you *need* to do
these steps for a stable product.

Comment 2

[Roger Bivand]

Upgrading from 0.1 to 0.3, I unpacked the tarball into a fresh directory,
numbered 0.1, then 0.3. Same for 0.3 -> 0.4. The only change was to copy&paste
flash plugins from release to release. So all the release files are in separate
directories phoenix-0.[134]. 0.1 created a ~/.phoenix, with the default profile
in it. Before running ./phoenix-0.3/phoenix -ProfileManager, I had made a
~/.phoenix-0.3 directory, and used that for putting the profile in. Moving to
0.4, I did the same - the profile was in ~/.phoenix-0.4 (but ~/.phoenix and
~/.phoenix-0.3 were still there - last modification times suggest that they
weren't being written to). Now I have completely removed ~/.phoenix and done
./phoenix-0.4/phoenix again, allowing the manager to create a ~/.phoenix
directory. I did remove the blank in "Default User" this time round - could it
be an underscore or point, please?

On another installation on another machine, no problem has arisen so far despite
the same install process (different phoenix-0.[134] directories, different
~/.phoenix directories). Is there someting that reads ~/.phoenix/* despite the
fact that the ProfileManager was pointed at a different directory?

Comment 3

[André Dahlqvist]

Please try the latest nightly build from:

http://ftp.mozilla.org/pub/phoenix/nightly

and instead of messing around with different profile directories, just move away
the old profile directories and use ~/.phoenix to test if this bug still happens.

Comment 4

[Asa Dotzler [:asa]]

If this is a bug then it's probably a Mozilla bug. Can you test the latest
Mozilla nightly build on that same failing machine? (That this particular thing
works on one of your machines and not another seems very odd to me)

Comment 5

[Roger Bivand]

As suggested, I've moved ~/.phoenix aside, installed the nightly build of
November 17, and see no problem.

My explanation is that while the profile manager makes it look as though the
user data can be kept in an arbitrary directory, it is actually hard-wired
somewhere to ~/.phoenix, so my original mistak was to point 0.4 at a new
directory _not_ named ~/.phoenix through the -profilemanager interaction,
assuming that this would propagate, but didn't, leaving the program trying to
use the old data. The modification times didn't support this unequivocally, though.

Conclusion: the warning at the head of the release notes page should stipulate
that the old ~/.phoenix directory be moved/removed before the new phoenix is
run, and that the option to point the program at a different directory in the
-profilemanager be revisited to see whether some parts of the program are not
still trying to access say ~/.phoenix, even though this isn't the current user
profile directory.

Comment 6

[Asa Dotzler [:asa]]

OK. thanks for the follow-up.

Comment 7

[Simon Paquet [:sipaq]]

Taking QA Contact as designated owner of Firebird-Menus. Sorry for bugspam.

Comment 8

[Simon Paquet [:sipaq]]

verified wfm