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)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: dobbinsj, Assigned: hyatt)

References

()

Details

(5 keywords, Whiteboard: relnote-user)

Crash Data

Attachments

(1 file)

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
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: rtmarch, 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: dogfoodnsdogfood
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 ago23 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: 23 years ago23 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: 23 years ago23 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.