Closed
Bug 225239
Opened 21 years ago
Closed 21 years ago
Preferences display is partly broken, app freezes
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
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.
Reporter | ||
Comment 1•21 years ago
|
||
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...
Reporter | ||
Comment 3•21 years ago
|
||
They could be guilty for this very annonying bug. But the problem is I have no JS console error :(
Updated•21 years ago
|
Flags: blocking0.8+
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
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).
Comment 6•21 years ago
|
||
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.
Comment 7•21 years ago
|
||
*** Bug 225273 has been marked as a duplicate of this bug. ***
Comment 8•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
Comment 11•21 years ago
|
||
Comment 12•21 years ago
|
||
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
Comment 13•21 years ago
|
||
If you select Preferences from the menu again, you regain control over the dialog.
Comment 14•21 years ago
|
||
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
Comment 15•21 years ago
|
||
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?
Comment 16•21 years ago
|
||
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.
Comment 17•21 years ago
|
||
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.
Comment 18•21 years ago
|
||
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".
Comment 19•21 years ago
|
||
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
Comment 20•21 years ago
|
||
*** Bug 225388 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•21 years ago
|
||
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
Assignee | ||
Comment 22•21 years ago
|
||
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
Comment 23•21 years ago
|
||
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.
Comment 24•21 years ago
|
||
*** Bug 225354 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
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
Comment 26•21 years ago
|
||
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.
Comment 27•21 years ago
|
||
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 ?
Comment 28•21 years ago
|
||
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.
Assignee | ||
Comment 29•21 years ago
|
||
I backed out the patch for bug 218297 it's not the guilty.
Comment 30•21 years ago
|
||
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?
Reporter | ||
Comment 31•21 years ago
|
||
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 ?
Comment 32•21 years ago
|
||
The bug is filed on Windows.... The theme used on OSX should not affect that...
Reporter | ||
Comment 33•21 years ago
|
||
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 ?
Assignee | ||
Comment 34•21 years ago
|
||
the bug also happens on linux gtk2+xft and freeBSD gtk2+xft. I can't do any testing til I get home this evening.
Comment 35•21 years ago
|
||
*** Bug 225480 has been marked as a duplicate of this bug. ***
Comment 36•21 years ago
|
||
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)
Comment 37•21 years ago
|
||
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.)
Assignee | ||
Comment 38•21 years ago
|
||
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.
Comment 39•21 years ago
|
||
Build from 2003-11-09 10:00 AM PST (immediately before jshin's checkin) does not show the flaw with a fresh profile.
Comment 40•21 years ago
|
||
Build from 11/09/2003 12:50 PST CLEAR. Looks like we can exonerate jshin's checkin.
Comment 41•21 years ago
|
||
11/09/2003 21:55 PST also doesn't show this problem...
Comment 42•21 years ago
|
||
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
Comment 43•21 years ago
|
||
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.
Comment 44•21 years ago
|
||
11/09/2003 10:00 PST works! Regression frame: 10:00 - 21:55. I'll try 12:50 PST next.
Comment 45•21 years ago
|
||
11/09/2003 12:50 PST works. New regression frame: 12:50 - 21:55. I'll try 14:50.
Comment 46•21 years ago
|
||
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 :(
Comment 47•21 years ago
|
||
export MOZ_CO_DATE="11/09/2003 14:00 PST" works for me export MOZ_CO_DATE="11/09/2003 20:00 PST" crashes
Comment 48•21 years ago
|
||
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.
Comment 49•21 years ago
|
||
I'm betting on this: 11/09/2003 15:25 ben%bengoodger.com mozilla/ toolkit/ mozapps/ jar.mn 1.3 0/4
Comment 50•21 years ago
|
||
export MOZ_CO_DATE="11/09/2003 17:00 PST" crashes
Comment 51•21 years ago
|
||
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.
Comment 52•21 years ago
|
||
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!?
Comment 53•21 years ago
|
||
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.
Comment 54•21 years ago
|
||
export MOZ_CO_DATE="11/09/2003 15:00 PST" works
Comment 55•21 years ago
|
||
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)
Comment 56•21 years ago
|
||
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.
Assignee | ||
Comment 57•21 years ago
|
||
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!
Reporter | ||
Comment 58•21 years ago
|
||
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 :)
Comment 59•21 years ago
|
||
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!
Updated•21 years ago
|
Flags: blocking0.8?
Comment 60•21 years ago
|
||
current CVS pull verified working on GTK+2/Xft on Linux
Assignee | ||
Comment 61•21 years ago
|
||
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
Reporter | ||
Comment 62•21 years ago
|
||
Confirming bug is dead. Yes :) Just need to make another build, in order to release it :)
Assignee | ||
Comment 63•21 years ago
|
||
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 :)
Comment 64•21 years ago
|
||
pch: that suggestion totally breaks if you run it somewhere other than $topsrcdir...
Assignee | ||
Comment 65•21 years ago
|
||
biesi: of course, it should only be run at the top level.
Comment 66•21 years ago
|
||
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!!!!!
Comment 67•21 years ago
|
||
*** Bug 225657 has been marked as a duplicate of this bug. ***
Comment 68•21 years ago
|
||
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 ?
Comment 69•21 years ago
|
||
It appears my last comment is related to http://bugzilla.mozilla.org/show_bug.cgi?id=221687
Comment 70•21 years ago
|
||
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
Comment 71•18 years ago
|
||
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.
Description
•