Closed Bug 225239 Opened 22 years ago Closed 22 years ago

Preferences display is partly broken, app freezes

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: fredbezies, Assigned: p_ch)

References

Details

(Keywords: crash, hang, regression)

Attachments

(3 files)

Huge save dialog in 2003-11-10
21.94 KB, image/gif
Details
Privacy options in 2003-11-09 (are normal)
31.82 KB, image/gif
Details
Privacy options in 2003-11-10 (are borked)
44.11 KB, image/gif
Details
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.
Attached image Huge save dialog in 2003-11-10 —
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: 22 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: