Closed Bug 225239 Opened 21 years ago Closed 21 years ago

Preferences display is partly broken, app freezes

Categories

(Firefox :: Settings UI, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: fredbezies, Assigned: p_ch)

References

Details

(Keywords: crash, hang, regression)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031110 Firebird/0.7+ (Gcc 3.3.1 i686 optimized - MozJF)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031110 Firebird/0.7+ (Gcc 3.3.1 i686 optimized - MozJF)

I have to say I am using a gcc-win32 based build. Sources used where up-to-date
at 08:00 am mozilla.org time.

When I ran the first time my new build, and when I try to go to tools/options,
it opens a big window, nearly a full screen.

After closing firebird (killing it), tools/options had the right size, but is a
gray windows, not a white and gray one.

Reproducible: Always

Steps to Reproduce:
1.Grab a tarball, and apply CVS updates on it
2.Build it using ming-win32 (.mozconfig is in additionnal comments)
3.Run the new bird, and go to tools/options and see.

Actual Results:  
Big gray windows. Have to kill firebird.

Expected Results:  
A standard white and grey prefs window.

mozconfig used :

CC=gcc
CXX=g++
CPP=cpp
AS=as
LD=ld

export MOZ_PHOENIX=1
mk_add_options MOZ_PHOENIX=1

ac_add_options --disable-ldap
ac_add_options --disable-mailnews
ac_add_options
--enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,transformiix,universalchardet,typeaheadfind,webservices
ac_add_options --enable-crypto
ac_add_options --disable-composer
ac_add_options --disable-profilesharing
ac_add_options --disable-installer

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../fbbuild

ac_add_options --disable-accessibility
ac_add_options --disable-debug
ac_add_options --disable-tests

ac_add_options --enable-strip
ac_add_options --enable-strip-libs

ac_add_options --enable-optimize="-Os -march=i686"
ac_add_options --disable-pedantic

I will try aebrahim build to see if I am not guilty here.
Aebrahim build is also having this bug. See this thread in mozillazine :

http://forums.mozillazine.org/viewtopic.php?t=34218
Potentially related to the checkin for bug 225150 or bug 221599, in a quick scan
those were the only ones I found that could have horked the pref panel...
They could be guilty for this very annonying bug. But the problem is I have no
JS console error :(
Flags: blocking0.8+
This is a comment I posted on the mozillazine thread where this bug is being
discussed that I thought should be moved here: 

"What time did those of you who're getting the tools/options bug pull the
source? I did a pull between the checkin for 221666 and 214387, (so about
5-530am PST or GMT-8). There's about 5 or 6 checkins I missed 2-3 hours after I
checked out CVS. Mine doesn't crash or do anything unusual with tools/options
with or without a new profile (built on fedora-core-1 gcc 3.3.2), but if the bug
was after I checked out CVS, I could apply each patch and figure out which
caused the regression."

Anyway, I'll try applying the 4 or 5 checkins (one at a time, of course) after I
checked mine out and built today and report back if any one of them causes this
regression. 
I tried to roll forward from where I was by applying the changes for patches
135607, 224251, and 75519, but either this is the wrong bug, or I just can't
duplicate the bug with a new profile (or an old one) on fedora, with gcc 3.3.2.
I know this bug says win2k, but the thread that points to it is mostly linux users. 

135607: doesn't cause the bug (3 files checked in)
224251: " " (1 file checkin)
75119: " "  (1 file checkin) (and up to date at this point).

I just went to Tools | Options and was presented with a huge grey window, which
we already know. More importantly, I was not able to exit this window. Try as I
might, the Cancel and X button did not work. Now it works again.

Also, this isn't only affecting the Options dialog. It also affects the open
file/save to disk dialog as well.
*** Bug 225273 has been marked as a duplicate of this bug. ***
Bug 225273 confirms this on MacOS X, and I can confirm that the dialog is the
wrong colour on Linux too (although no funky huge dialogs on Linux, yet). -->
All/All.
OS: Windows XP → All
Hardware: PC → All
Since I didn’t see this bug when I posted 225273, I’ll also note here that when the huge 
preferences dialog rears its head, it uses the new Panther sheet animation. When it behaves 
properly, it uses the old animation.
Note the following:

- The dialog is huge.
- The buttons don't work. I've clicked on the Privacy tab, but it's displaying
the General prefs.
- The colouring of the dialog box is incorrect.
- I can't get rid of this dialog. Only way is to kill MozillaFirebird.exe
If you select Preferences from the menu again, you regain control over the dialog.
I'm seeing this too on the 2003-11-10 WinXP nightly (fresh profile, no
themes/extensions) 

-> pch, whose checkin for bug 221599 and bug 225150 is probably the cause of this.
Assignee: blake → p_ch
Severity: normal → critical
Keywords: hang
Summary: Preferences display is partly broken = wide grey window. → Preferences display is partly broken, app freezes
miaomx5, don't plus the blocking-flag. This is a developer-only option. You may
nominate a bug for blocking status by setting the blocking?-flag.
Flags: blocking0.8+ → blocking0.8?
Simon,

I backed out the changes for those bugs using the following:

cvs update -j1.4 -j1.3 mozilla/toolkit/mozapps/downloads/content/helperApps.js
cvs update -j1.2 -j1.1 mozilla/toolkit/mozapps/downloads/content/overrideHandler.js

However, after rebuilding, I'm still seeing the bug, unfortunately.
I can confirm the Big blank gray window with no buttons in both Linux and Mac OS X.  The Firebird 
Build on the OS X 10.3 system was pulled late November 9th, the Linux build pulled from CVS this 
morning.  Have yet to have the Linux pull give me the right dialog (GCC 3.3.2, GTK+-2.0)

In both case needed external assitance (Force quit and kill respectively) to exit the application.
I spent some more time staring at the list of checkins, and the only other thing
that sticks out to me is Ben's checkin for bug 204733 (he doesn't reference a
specific bug number in the comment, but that's the bug) "Use Pinstripe Theme for
Mac OS X".
I can reproduce this with a new profile. It works fine using my old profile.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031111
Firebird/0.7+ (Steffen)
Keywords: regression
*** Bug 225388 has been marked as a duplicate of this bug. ***
this is what we get on the console, before the crash (gtk2):

###!!! ASSERTION: couldn't get thread private index:
'nsThread::kIThreadSelfIndex != 0', file nsThread.cpp, line 376
Break: at file nsThread.cpp, line 376
Type Manifest File: /home/chanial/mozilla/debug/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
WARNING: Error parsing GRE default preferences. Is this an old-style embedding
app?, file nsPrefService.cpp, line 757
GFX: dpi=96 t2p=0,0666667 p2t=15 depth=24
WEBSHELL+ = 1
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsChromeRegistry.cpp,
line 3185
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsChromeRegistry.cpp,
line 3185
WEBSHELL+ = 2
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
WEBSHELL+ = 3
WEBSHELL+ = 4
WARNING: NS_ENSURE_TRUE(window) failed, file nsContentTreeOwner.cpp, line 643
WARNING: NS_ENSURE_TRUE(docShellElement) failed, file nsXULWindow.cpp, line
1304WARNING: NS_ENSURE_TRUE(windowElement) failed, file nsXULWindow.cpp, line 1358
###!!! ASSERTION: no xul:window: 'windowElement', file nsXULWindow.cpp, line 1068
Break: at file nsXULWindow.cpp, line 1068
###!!! ASSERTION: no xul:window: 'windowElement', file nsXULWindow.cpp, line 1002
Break: at file nsXULWindow.cpp, line 1002
###!!! ASSERTION: no xul:window: 'windowElement', file nsXULWindow.cpp, line 1146
Break: at file nsXULWindow.cpp, line 1146
WARNING: NS_ENSURE_TRUE(windowElement) failed, file nsXULWindow.cpp, line 978
GTK theme failed for widget type 87, error was 4, state was
[active=0,focused=0,inHover=0,disabled=0]
WARNING: GTK theme failed; disabling unsafe widget, file nsNativeThemeGTK.cpp,
line 421
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 4267 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Keywords: crash
run --sync in gdb isn't helpful, since just after 'WEBSHELL+ = 3', gdb can't get
a thread and blocks at that point.

cc'ing people. I confirm comment 19: the crash (at least for a debug build with
gtk2+xft) only occurs for new profiles.

bsmedberg: that may be unrelated, but could you comment on the assertion:
WARNING: Error parsing GRE default preferences. Is this an old-style embedding
app?, file nsPrefService.cpp, line 757

I must mention the fact that this only happens when the browser window is
maximized before opening the options; all other times it is normal.
*** Bug 225354 has been marked as a duplicate of this bug. ***
pch: the warning is probably entirely unrelated, it exists because of bug
212222. We're splitting apart default prefs into "GRE default prefs" and
"application default prefs"; the backend work in the prefservice is done, but
the actual splitting of pref files hasn't happened yet.

--BDS
Just to narrow things down a bit. The 2003-11-09 official Win32 build doesn't
exhibit this bug for me. My CVS build which I pulled at midnight 2003-11-10
does. So the checkin that caused this bug is probably within this time period,
from when the source pull for the 2003-11-09 official build began, to midnight
2003-11-10. That's probably about a 15 hour window or so, depending on when the
CVS pull for the official build began.
Is this FB-only or also a problem in SeaMonkey?

> which I pulled at midnight 2003-11-10 does

As in, at the beginning of the day on 2003-11-10?  If so, could you try backing
out the patch for bug 218297 ?
bz,

Yes, the beginning of the day. I backed out the fix for bug 218297 (and also bug
197294) using the following commands at the top of my tree:

cvs update -j1.314 -j1.312 mozilla/content/html/content/src/nsHTMLInputElement.cpp
cvs update -j3.7 -j3.6 mozilla/layout/base/public/nsIPresState.h
cvs update -j1.3 -j1.2 mozilla/layout/base/public/nsLayoutErrors.h
cvs update -j3.20 -j3.19 mozilla/layout/base/src/nsPresState.cpp

Rebuilt, and it's still locking up my Linux system when I go to Tools | Options.
So I don't think its those checkins.
I backed out the patch for bug 218297
it's not the guilty.
Any chance of just doing a binary search on the checkins in that time period
(several pulls by date) or just backing out patches one at a time
indiscriminately until you find the problematic one?
It could be completely stupid, but I'm trying my luck (!).

New OS-X interface was added on 9th november. Could it possibly be guilty for
this displaying bug ?
The bug is filed on Windows....  The theme used on OSX should not affect that...
I know that the bug was originally filled on windows. But comment #7 and #8, it
also happens on OS-X.

My comment was just an idea. It could be (or not) a way to follow and get a
solution ?
the bug also happens on linux gtk2+xft and freeBSD gtk2+xft.
I can't do any testing til I get home this evening.
*** Bug 225480 has been marked as a duplicate of this bug. ***
I did test Options->Preferences with a non-maximised window, and depite the fact
that it the Preferences pop-up does not respond quickly, it remains fully
functional and does NOT crash the browser. (Win2k/FB 20031112)
Just confirming the crash on a new CVS pull as of about 13:00 GMT built as a
debug build with GTK2 and XFT on linux.

The whole browser crashes when Tools > Options is selected. A small window opens
for less than a second. The following is dumped to the console:

WARNING: NS_ENSURE_TRUE(window) failed, file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 643
WARNING: NS_ENSURE_TRUE(docShellElement) failed, file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1304
WARNING: NS_ENSURE_TRUE(windowElement) failed, file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1358
###!!! ASSERTION: no xul:window: 'windowElement', file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1068
Break: at file /usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1068
###!!! ASSERTION: no xul:window: 'windowElement', file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1002
Break: at file /usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1002
###!!! ASSERTION: no xul:window: 'windowElement', file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1146
Break: at file /usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1146
WARNING: NS_ENSURE_TRUE(windowElement) failed, file
/usr/src/mozilla/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 978
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 5215 error_code 2 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
I backed out Darin's patch about nsURIChecker with no luck.
swalker backed out danm's checkin, same result.

Ben is building at 10:00 PST before jshin's checkin
I am building at 14:00 PST after jshin's checkin.

Anybody with a build environment can help narrowing down the regression here by
picking a pulling date between 11/09 08:00 PST and 11/10/08:00 PST.
To pull by date, do the following:
setenv MOZ_CO_DATE "11/09/2003 14:00 PST"
gmake -f client.mk
the build script will do the rest.
Build from 2003-11-09 10:00 AM PST (immediately before jshin's checkin) does not
show the flaw with a fresh profile. 
Build from 11/09/2003 12:50 PST CLEAR. 

Looks like we can exonerate jshin's checkin. 
11/09/2003 21:55 PST also doesn't show this problem... 

Similar to comment 37, I get a crash on RH9/gtk2+xft with a fresh cvs pull and
using an old profile, prior to that I was doing depend builds and saw no crashes
or strange display when going to Tools->Options

11/09/2003 21:55 PST is broken here on WinXP with a new (created just before
using it the first time) profile.
The cvs co commands showed the correct -D 11/09/2003 21:55 PST.

I'll try 10:00 PST next.
11/09/2003 10:00 PST works! Regression frame: 10:00 - 21:55.

I'll try 12:50 PST next.
11/09/2003 12:50 PST works. New regression frame: 12:50 - 21:55.
I'll try 14:50.
14:50 works, and so does 21:55, which I tried again. Oh dear. Please ignore
comments 43 - 45.
I'll start over and do a "make clean" each time. But this will take ages :(
export MOZ_CO_DATE="11/09/2003 14:00 PST" works for me
export MOZ_CO_DATE="11/09/2003 20:00 PST" crashes
Now the "clean" builds:
14:50 works.
21:55 broken. I'm so happy to see a broken build again! ;-)
I'll try 15:30.
I'm betting on this:

11/09/2003 15:25	ben%bengoodger.com 	mozilla/ toolkit/ mozapps/ jar.mn 	1.3 	0/4 
export MOZ_CO_DATE="11/09/2003 17:00 PST" crashes
Re comment #49, I am doing a build, now restoring the code that the above
mentioned checkin removed from jar.mn.  Will let hyou know the results.  BTW
another symptom of this is that the option -> Themes window does not render
correctly.
15:30 is partly broken. The size of the options dialog is normal and the buttons
work, but it's all in grey with a fresh profile.
So these are two separate regressions!?
Sorry, that was wrong.
15:30 is broken as well. I tried it about 5 times, each with a new profile, and
every time it showed me the giant options dialog with the buttons that don't work.
Sorry for spamming around.

The regression frame is now 14:50-15:30.
I'll try 15:00.
export MOZ_CO_DATE="11/09/2003 15:00 PST" works
The build without this:

11/09/2003 15:25	ben%bengoodger.com 	mozilla/ toolkit/ mozapps/ jar.mn 	1.3 	0/4

checkin does NOT exhibit the problem.  The Tools-> options window comes up
normal size and the Tools -> Options -> Themes window displays correctly (the
white border and scroolbars appear surrounding the sample of the modern theme)
At 50% windowsize Options opens
--Focus is on last choosen Option
--General is highlighted like with mouseover
--The other options can be highlighted with the mouse.
Leaving you with 1 focus and 2 highlighted options.
It seems like William is the happy winner !
I just ckecked in a fix to package the skin contents.rdf file. It should fix the
bustage.

I can't build here, so please could someone verify it?

And a BIG THANK to all of you that help track down this regression. This
combined effort was quite amazing and efficient!
As the bug reporter, can I be the verifier, please ?

NB : doing a checkout right now, and it will take me 90 minutes to build a
firebird :)
I'll backout these changes with
cvs update -j1.5 -j1.4 mozilla/toolkit/mozapps/jar.mn
cvs update -j1.4 -j1.3 mozilla/toolkit/mozapps/jar.mn
and build again,
and? IT'S WORKING!
Flags: blocking0.8?
current CVS pull verified working on GTK+2/Xft on Linux
great!
marking fixed. But make sure you have a clean chrome.

btw, bsmedberg, would you be interested in implementing sth like
make cleanchrome or chromeclean?
It would simpy do:
rm -rf dist/bin/chrome
make chrome
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Confirming bug is dead. Yes :)

Just need to make another build, in order to release it :)
While I am at it, Gecko shouldn't have crashed but instead should have reported
an error, here.
bsmedberg, it seems like it's some more work fitted for you :)
pch: that suggestion totally breaks if you run it somewhere other than $topsrcdir...
biesi: of course, it should only be run at the top level.
Oh boy. No wonder I wasn't seeing this in all of my builds, I wasn't blowing
away installed-chrome.txt and thus the skin was still registered. 

Sigh. This was part of the pinstripe landing. Sorry!!!!!
*** Bug 225657 has been marked as a duplicate of this bug. ***
Read comment #56.
In:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031114
Firebird/0.7+zip
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031114
Firebird/0.7+installer
This is not Fixed.
see comments by various in
http://forums.mozillazine.org/viewtopic.php?p=263430&sid=20345c34e1d1166f2276f6d3a89d4c1d#263430

Maybe this has to be moved to a new bug# so the crash issue can be closed ?
It appears my last comment is related to
http://bugzilla.mozilla.org/show_bug.cgi?id=221687
It initially appeared that besides the crashing and some cosmetic things, the
problems were solved. This is unfortunately not the case. After a while the
functionality fails.
In Options:
1) Navigations - keeps working (but highlight bug)
2) General - keeps working
3) Privacy - worked at first, failed after a few times.
 It is not possible to clear any part or even save a changed chache size,
4) Filetypes ... has forgotten what to do with e.g. zip (icon missing)
5) No comment about themes/extensions , none used here
6) Advanced keeps working
7) OK/Cancel buttons are ok
tested on :
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031114
Firebird/0.7+ zip and installer version
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: