Closed Bug 53670 Opened 24 years ago Closed 23 years ago

Implement versioning in chrome registry (New build won't start if 3rd party theme is used in old build [@ nsCSSFrameConstructor::ConstructDocElementFrame])

Categories

(Core Graveyard :: Skinability, defect, P3)

Product:
Core Graveyard
Component:
Skinability
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: dobbinsj, Assigned: hyatt)

References

(
URL
)

Details

(5 keywords, Whiteboard: relnote-user)

Crash Data

Attachments

(1 file)

Patch to support versioning.
6.37 KB, patch
Details | Diff | Splinter Review
If a third party theme was used before a new nightly build is installed the new build displays the splash screen, then freezes. No talkback report is generated. I first saw this with 0915 build. At first I just deleted the usual files to get the build to work, but that got old. To reproduce. 1. download a theme from http://x.themes.org/viewresources.phtml?type=chrome 2. Install the theme, then quit Mozilla 3. Install a new nightly build in another folder. 4. Attempt to launch the new build - It freezes. If you return to the old build and switch the theme to Classic, Modern, or Blue then the new build will launch with no problem. Mozilla should go to the default theme if the selected theme isn't avaible.
--themes (i think)
Assignee: asa → hangas
Component: Browser-General → Themes
QA Contact: doronr → pmac
I suspect this is a wontfix. we're a moving target for theme makers right now but that's what happens in software development. When things stop moving then bugs like this (if they are still happening) will get attention.
This problem gets worse if PR3 is installed. 1. If Classic or Modern wasn't the last theme used in Mozilla, PR3 won't Start on the inital install. 2. If a theme is used in PR3 and that theme isn't also present in Mozilla, Then Mozilla won't start. 3. The only way Mozilla and PR3 will work normally is if BOTH have the same themes installed. Whem RTM is released, Anyone upgrading from PR3 will find that RTM will not work if they used a Third party theme the last time they used PR3, or Mozilla.
Keywords: rtm
Sounds like a skinability bug
Assignee: hangas → ben
Component: Themes → Skinability
QA Contact: pmac → blakeross
Problem also occurs on Linux, updating OS to all. adding crash keyword. Problem is when Mozilla/Netscape reads the user-skins.rdf file in the profile, it freezes if that theme isn't installed in Chrome. This can occur when a 3rd party theme is used and the user is, 1. using multiple Mozilla builds for trouble shooting or development. 2. updating a Mozilla build. 3. using both Mozilla and PR3 4. Theme file is corrupted or deleted 5. Will occur when a user updates from PR3 to RTM I haven't tested this, but probably occurs if Blue is used in Mozilla and User tries to start PR3. This problem first occured in the 0915 nightly build.
Keywords: crash
OS: Windows 98 → All
Hardware: PC → All
Freezes are by definition bugs. CONFIRMing. Asa, I disagree. Mozilla is always in *constant* change, so this is not an exceptional situation, not even for N6.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This will never work. When you install a skin, the user-skins.rdf file in your profile is updated to reference the new skin, e.g. resource:/chrome/foopyskin/etc/etc... When you install a new build into a different folder, but are using the same profile, the new build will try to launch skin files that do not exist. This will never work, unless the skin is installed into the profile directory. Reassigning to hyatt, setting rtm-, and marking future.
Assignee: ben → hyatt
Whiteboard: [rtm-]
Target Milestone: --- → Future
This Bug will crash RTM! Any body who uses themes in PR3 Will find that When they upgrade to RTM Netscape 6 will freeze up on the inital launch. NS marketing is pushing Themes as a major feature. Many PR3 Users will be using this feature. Unless this bug is fixed or the RTM installer wipes PR3/Mozilla profiles the user will think that the RTM upgrade failed.
I also think this will cause some serious problems when people upgrade to ns6rtm. Could we maybe have some sort of fallback so that if the specified theme doesn't exist it will regenerate the necessary files in your profile to use the default theme? At least relnote for ns6 and try to get it into mozilla0.6
Keywords: mozilla0.6, relnote, relnoteRTM
This definitely sucks, and we need to make sure it is addressed for the next release, as people will certainly run into this situation frequently by that time. I don't think we're going to be able to address this for RTM obviously, but fortunately it is a very small number of users of PR3 that will have installed a third party theme that will be affected. Also, these affected users are generally going to be very savvy users who will understand the problem (or know about it already from this bug). Vera, did can we get this into the release notes?
Whiteboard: [rtm-] → [rtm-] relnote-user
Hyatt, did your fix for bug 57733 affect this at all?
Tested with nightly trunk build 102504 on win98 SE. I don't know if it's related to Hyatt's fix for bug 57733, but the problem is worse. I attempted to start Mozilla using a profile set to a third party theme. Mozilla now crashes instead of freezing. Talkback sent. 98 reports MOZILLA caused an invalid page fault in module GKHTML.DLL at 017f:602510cd. Registers: EAX=00000000 CS=017f EIP=602510cd EFLGS=00010246 EBX=0068f43c SS=0187 ESP=0068f35c EBP=0068f3e4 ECX=0068f3f0 DS=0187 ESI=00000000 FS=64b7 EDX=0068f3d4 ES=0187 EDI=01e98540 GS=0000 Bytes at CS:EIP: 8b 08 ff 51 6c 8b 45 0c 8d 55 10 89 75 10 52 8b Stack dump: 00000000 0068f3d4 01e98540 01e99e20 00000000 01e99e20 0068f384 00000000 60ce713d 01e99750 6028ecf5 01e98540 01e98540 0000000c bff7b9c5 81aa58e0
Adding topcrash keyword. This is showing up in trunk and branch talkback reports with signature nsCSSFrameConstructor::ConstructDocElementFrame . See http://www.mozilla.org/projects/seamonkey/reports/ns6analysis.html for trunk details.
Keywords: topcrash
Summary: New build won't start if 3rd party theme is used in old build → New build won't start if 3rd party theme is used in old build [@ nsCSSFrameConstructor::ConstructDocElementFrame]
Sorry, you can't expect this to work for old themes.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
*** Bug 59106 has been marked as a duplicate of this bug. ***
*** Bug 61922 has been marked as a duplicate of this bug. ***
Why is this still a WONTFIX? It is a serious bug and might put off users, especially now that themes are more stable trivial to download and install and people start trying. Solution: 1) Either make chrome part of profile. Is there any reason for not doing this? After all, it's a personal preference. 2) After update ALWAYS default to built-in theme. Again, there is no reason for not doing this if themes are not part of the profile.
*** Bug 64002 has been marked as a duplicate of this bug. ***
A crash in a product when the product is the problem should never be marked WONTFIX. Why can't we, upon seeing that our theme isn't present, simply revert to using the default theme as shipped in the product? If that's not present a list of available themes to select from before going any further, and if NO themes are installed, pull up a dialog asking the user to install some themes, click OK and then we exit. Either way we should never just crash and mark WONTFIX. I invite reasons why we cannot reopen this bug :)
In light of comments above, reopening.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
we missed 0.6. Killing the keyword
Keywords: mozilla0.6
Nominating for Mozilla 0.9, this really needs to be fixed before 1.0
Keywords: mozilla0.9
I too have had this nightmare happen to me several times now. It took me multiple attempts to figure out how to avoid it. usually, i just copy the new nightly build over the old one and thing work OK. But occasionally, i like to delete the mozilla dir and copy the files fresh. This is when the nightmares begin, because by then i have forgotten how i solved the puzzle of getting mozilla to run again. The best solution is to default to the default skin if the last selected one is no longer available. Maybe there should also be a small dialogue window explaining to the user why suddenly his mozilla looks different. I don't think the skins should be stored in the profile because that would waste a lot of space - transportability of profiles.
*** Bug 65375 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 65530 has been marked as a duplicate of this bug. ***
Keywords: hang, nsbeta1
I don't know if this is the same bug. Today I tried to run Mozilla and it opened kind of a browser window with only an XML Parsing Error: undefined entity Line Number 40, Column 0: <window id="main-window" xmlns:html="http://www.w3.org/1999/xhtml" ^ (the 3 lines above are rendered exactly like this in the window). What I did to get to this problem? I just installed a few themes from x.themes.org . Note that I was still able to use the browser when these were installed. Creating a fresh profile doesn't solve the problem. I know that if you run into the problem of a theme that is not available, creating a new profile, installing the theme that is not available, switching to it and starting with the old profile solves the problem). So this is really an evil one... This problem is occurring with the 20010117 build on windows 98
*** Bug 66470 has been marked as a duplicate of this bug. ***
*** Bug 66622 has been marked as a duplicate of this bug. ***
*** Bug 67273 has been marked as a duplicate of this bug. ***
*** Bug 67035 has been marked as a duplicate of this bug. ***
With build 2001020504 the old themes are still available after installation. Before installation, I switched to modern theme to avoid hanging upon start of new build. After installation I switched back to native.windows theme being suprised by its existence in the list. Mozilla crashed immediately. I restarted and Mozilla went straight into native.windows theme without crashing. It seems to work now.
*** Bug 69102 has been marked as a duplicate of this bug. ***
This really should be fixed, especially since we're looking to release the next major version of NS6 one of these days. Adding myself to cc list, adding dogfood to the keyword pile.
Keywords: dogfood
*** Bug 70227 has been marked as a duplicate of this bug. ***
let's assume this is a profile manager bug. when a profile starts to load, if it can't find the skin it wants to use, it should fall back to a default skin.
Assignee: hyatt → dveditz
Status: REOPENED → NEW
Keywords: rtm → arch, helpwanted
Whiteboard: [rtm-] relnote-user → relnote-user
Target Milestone: Future → ---
Let's assume we've already talked with Hyatt and had found the right home for this issue which needs to be solved in the Chrome Registry.
Assignee: dveditz → hyatt
Hyatt -- just noticed the lack of target milestone. This *is* one of the two theme/version bugs you agreed to fix in the theme meeting, isn't it? (the other being the very similar fall back to the default if the version of the selected theme is old)
-> moz0.9
Keywords: dogfood → nsdogfood
Summary: New build won't start if 3rd party theme is used in old build [@ nsCSSFrameConstructor::ConstructDocElementFrame] → Implement versioning in chrome registry (New build won't start if 3rd party theme is used in old build [@ nsCSSFrameConstructor::ConstructDocElementFrame])
Target Milestone: --- → mozilla0.9
*** Bug 64803 has been marked as a duplicate of this bug. ***
*** Bug 72711 has been marked as a duplicate of this bug. ***
looks great, sr=waterson
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
*** Bug 71797 has been marked as a duplicate of this bug. ***
This has NOT been fixed. I moved my old (16th March) Mozilla to a backup dir (mv /usr/lib/mozilla /usr/lib/mozilla_back), expanded the new 20th April daily tarball, and ran once as root to build any chrome. Then I went to run it as my normal user account. dylang@shadowgate:~$ /usr/lib/mozilla/mozilla /usr/lib/mozilla/run-mozilla.sh /usr/lib/mozilla/mozilla-bin MOZILLA_FIVE_HOME=/usr/lib/mozilla LD_LIBRARY_PATH=/usr/lib/mozilla:/usr/lib/mozilla/plugins:/usr/local/qt/lib:/usr/local/qt/lib LIBRARY_PATH=/usr/lib/mozilla:/usr/lib/mozilla/components:/usr/local/qt/lib:/usr/local/qt/lib SHLIB_PATH=/usr/lib/mozilla LIBPATH=/usr/lib/mozilla ADDON_PATH=/usr/lib/mozilla MOZ_PROGRAM=/usr/lib/mozilla/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= /usr/lib/mozilla/run-mozilla.sh: line 72: 3272 Segmentation fault $prog ${1+"$@"} SIGH! This means I have to spend some time finding where Mozilla has decided to store my profile (not in .mozilla for some reason, I wish I knew why), rename it, let it generate a "Safe" one, go and reinstall the theme ( http://x.themes.org/php/download.phtml?object=resources.chrome.966881489 ) .. could we have some more thorough testing as to why this is not working and I have to bend over backwards?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Another note: when I went and redownloaded the skin and tried to apply, it failed. (IE: the browser did not change appearance) Rather than rollback to classic look, Mozilla saved the new user-skins.rdf.. once again crashing on startup after the next load. Perhaps some sanity checking which rolls back to a working skin which is installed on a failed switch, or if one is supposed to be there (but is not) during initial load.
The themes on x.themes.org are not real themes, and I will not support them. They use XPIs that actually overwrite data in your INSTALL directory... in other words they monkey with data in a way that normal skins (installed using the normal skin installer) do not. I will not support these themes. When you download them, you do so at your own risk. If you find a bug involving normal skins and versioning, then I'll look at it, but I won't waste my time with the pseudo-themes on x.themes.org.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Ahh, but there is one thing that really should not crash Mozilla. And that is having a user-skins.css which refers to non-existant skins. Where is your sanity checking, eh? I told you that I unpacked a totally new build of Mozilla into its own NEW directory. The only old thing which caused the crash was my user-skins.css. This is obviously a correctness issue. Sanity checking in the XPI bootstrap with a fallback to ok skins would be very much appreciated.
QA Contact: blakeross → pmac
Based on David Hyatt, dated 4/20/01, The themes on x.themes.org are not real themes and David does not support these theme. Verified.
Status: RESOLVED → VERIFIED
According to our Crash Analysis for M091 Builds there were 237 talkback reports submitted over the last 10 days for nsCSSFrameConstructor::ConstructDocElementFrame which gives it the dubious honor of being our #1 topcrash bug. Reopening for reconsideration. Here are the comments from the 2001060713 build: (31471650) Comments: Extracted the "mozilla-win32-0_9_1-talkback.zip" file (31471495) Comments: Changing skin (31471354) Comments: Starting Mozilla v0.9.1 (31470989) URL: www.chosun.com (31470656) Comments: I have just install a v0.9.1 mozilla.... (31470621) Comments: Just checking to see if old themes work with new Moz...guess I know now. (31470493) URL: www.chosun.com (31470487) URL: www.chosun.com (31470485) URL: www.chosun.com (31470474) URL: www.chosun.com (31470474) Comments: I tried to change UI theme to the gray morden(?). (31470105) Comments: mozilla was starting up for the first time. crashed. pretty simple. still better than netscape6 though -=] (31469925) Comments: Just launching it! (31469797) Comments: installed mozilla 0.91crashes immediately at launch (31469191) Comments: starting after install of mozila 0.9.1 (31469097) Comments: Starting Mozilla 0.9.1 for the first time (31468415) Comments: Tried to load (31468410) Comments: Tried to load (31468406) Comments: Tried to load (31468336) Comments: Tried to load (31468327) Comments: Tried to load (31468300) Comments: Crashed while loading after installation (31468182) Comments: Startup (31467975) Comments: Starting up I get a GKLAYOUT.DLL error. (31467732) Comments: welp... mozilla 0.9.1 is a crash crazy thing! aie! back to 0.9 for muh i guess (31467604) Comments: it did it again! crashed on launch!aie... lemme reboot i guess =\ (31467521) Comments: i just installed mozilla... was gonna run it... crashed on launch (31467456) Comments: I simply tried to start mozilla the first time! I already had .9 installed (31465601) Comments: Starting the mozilla.exe program. (31465237) Comments: Tried to start Mozilla 0.9.1 after upgrade from 0.9.0. Other profiles start fine. (31464593) Comments: loading mozilla for the first time after install (31464507) Comments: crash during install (31464367) Comments: Tried to start it. Crashed (31463999) Comments: Mozzila.exe - Entry Point Not FoundEntry Point: ??_7nsLocalString@@6B@ in xpcom.dll (31463346) Comments: installing mozilla 0.9.1
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
That has nothing to do with this bug. That crash is covered under 77716.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Sorry, I didn't see that bug since someone had removed the stack signature from the summary line.
re-verify based on Comments From Patty Mac 2001-06-04 15:27.
Status: RESOLVED → VERIFIED
Also implement theme versioning. Attempting to install exactly the same theme twice (same url, same file, same version, good first install, no browser restart) goes on without any warning or complaint that the theme already exists. Luckily it doesn't appear twice in the themelist.
Keywords: relnote, relnoteRTM
Product: Core → Core Graveyard
Crash Signature: [@ nsCSSFrameConstructor::ConstructDocElementFrame]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: