Closed Bug 131016 Opened 22 years ago Closed 22 years ago

Current "nightly" is hosed. Menu, address bar are gone, xul in the browser window

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: zevious, Assigned: netscape)

References

Details

(Keywords: regression)

Attachments

(4 files)

Screenshot showing the problem
63.18 KB, image/jpeg
Details
screenshot with 2002031903
15.78 KB, image/gif
Details
winxp probems ( 2002031903)
79.23 KB, image/png
Details
don't autoreg generated embedding jar files
3.44 KB, patch
bryner
: review+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020311
BuildID:    2002031404?

Current "nightly" is hosed. Menu, address bar are gone, xul in the browser window

Reproducible: Always
Steps to Reproduce:
1. Download latest
2. install
3. Hosed

Actual Results:  Hosed display

Expected Results:  Nice workable browser
worksforme, linux build 2002-03-14-08
works for me 2002031403 on WInXP.
I get the same results. No menu, one line content area, one line status bar, and
the rest of the browser window shows red lines of code.
also see bug 130331. Looks similar.


This is only with the 2002-03-14-11-trunk build.  The earlier
2002-03-14-05-trunk build is working okay.
I slao see this on Win98SE, same build. It looks very similar to bug 130331
indeed from the scrennshot in that build. See my screenshot coming for
comparison, although it seems a bit worse in my case, aded to the fact that the
buttons doesn't work...

Anyways, confirming, but maybe a dup of bug 130331
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm seeing this with Win2k 2002031403
this looks as bad as in bug 127044
screenshot at http://www.jaygarcia.com/Half_Window.gif
I'd say both this and bug 130331 are dups of bug 127044
->hewitt
Assignee: trudelle → hewitt
*** Bug 131099 has been marked as a duplicate of this bug. ***
this was fixed this morning (03/15/02) but as of the 11:45 build it is toast
again.  
I see that there was a checkin by rods@netscape.com that was backed out since
this morning. Could this be related?

I installed the win32 zip time stamped 07:45 and it worked. Installed the one
time stamped 12:09, and it doesn't work. Both show 2002031503 as the build. Just
comfirming that the earlier one works and the later one (330k larger) does not.

Why isn't this a blocker on the tree being open? The latest is unusable so I can
not test the latest checkins...
The download that does *not* work includes the embed.jar file while the download
that does work, does not have this file. Hope that helps... and I agree, this
should be a blocker.

The "bad" one has embed.jar listed in installed-chrome.txt

Good catch. I downloaded the 12:09 build, removed the embeded.jar stuff from
installed-chrome.txt and it works fine..
*** Bug 131422 has been marked as a duplicate of this bug. ***
What makes this worse is if you have mozilla configured to start with Mail&News
only and not Navigator then it just hangs on the splash screen with builds
2002031411 and 2002031510 on Windows XP. Going back to build 2002031309 and it
works fine.
My build 2002031309 (win32-talkback.zip) comes with an embed.jar and that build
works fine. I've tried using the embed.jar from that build in a later build but
mozilla still has a hosed display, so it's possibly not the embed.jar that is
bust but something that makes use of it. As Kenneth said if you delete the
references to embed.jar from the installed-chrome.txt, build 2002031511 works as
it should.
Just tested BuildID 2002031708 on win32 and the problems seem to have been
fixed. Presumably this bug is a dupe of another bug that was fixed but not sure
which.
Marking worksforme per comments. If you see this again, please reopen...
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
The exact same thing again today. The earlier trunk (2002-03-18-05-trunk) win32
zip file does not include embed.jar nor is it installed in the
installed-chrome.txt file. This one works. The later trunk win32 zip
(2002-03-18-09-trunk) does include the embed.jar file, it is registered in
installed-chrome.txt and does not work. This bug needs to be reopened (and I
can't do it).

I still see this bug using today's build.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
OS: Windows NT → All
I am seeing this also on today's Win32 (W2K) build of 2002031803.

Should this be reopend?
-->Build Config?
It was definitely fixed in build ID: 2002031711 and broken again in build ID:
2002031809. Probably needs to be marked as a regression.
Looking a bit closer, the build from the weekend (17th March) for Win32 didn't
include embed.jar or reference to it in the installed-chrome.txt file. The build
from 13th March did include embed.jar but it was not referenced in the
installed-chrome.txt file.
*** Bug 131961 has been marked as a duplicate of this bug. ***
Keywords: regression
I just updated to the early 2002031903 from 20020312 (was blocked by
the proxy authentication bug).NT4.
Though the browser window is fine and works (I'm filling this bug with
this version) all the rest is broken (see attached screenshot).

FYI, no embed.jar neither any reference to it in installed-chrome.txt

I still have got problem with early 20020319 on Win2K.

    
    

    
  
I still have part of this problem on the early 2002031903 Win32 talkback build.

I don't have the menus (file,edit,...).  I do have back and forward, and my 
location bar, but don't have the images just the text like "Back" "Forward" etc.

My web page window for the bowser is back to normal size, but there seems to be 
a thick board around the edge that was not there before.

Are people that are seeing this all using the win32 talkback or other 
variations?


    
    

    
  
Alan,
Are you seeing the same as in attachment #74985 [details]

    
    

    
  
I fixed this at 3am last night. Can someone test this on a later build? I'm
downloading the 5am build right now, but my personal build works fine now.
Assignee: hewitt → alecf
Status: REOPENED → NEW

    
    

    
  
marking FIXED, as this was fixed early early this morning
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
Alecf, the 10:55 mozilla-win32.zip build (in the 2002-03-19-10-trunk directory)
still has this problem.

    
    

    
  
Build at 11:10 has the problem.. embed in installed-chrome. Works fine with the
removal of that.. seems like someone's tree doesn't have this change?

    
    

    
  
I just find that really odd because I'm using the 2002-03-19-08 windows build
and it works fine. (posting to this bug right now with it)

    
    

    
  
I just downloaded the 11:10 build from today and I still see this bug.
Summary: Current "nightly" is hosed. Menu, address bar are gone, xul in the broser window → Current "nightly" is hosed. Menu, address bar are gone, xul in the browser window

    
    

    
  
so talking with Kowalski on IRC, it sounds like this is an problem only on
non-installer builds....
reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
reassigning to jj for installer issues (sorry if I've got the wrong person)
Assignee: alecf → jj
Status: REOPENED → NEW

    
    

    
  
testing the latest 03/19 zipped builds it is still horribly broken. Testing the
installer builds it seems to be OK. 

    
    

    
  
that is *very* odd. I'm taking this bug, but reducing the severity. Alec, you're
not seeing this behaviour in a built tree, right?
Assignee: jj → leaf

    
    

    
  
technically, this is not a smoketest issue (since the installer-installed
binaries are the "supported" application for smoketests). removing keyword, but
i'll check the build system for any errors creating the .zip file.
Status: NEW → ASSIGNED
Keywords: smoketest

    
  
Keywords: nsbeta1

    
  
Priority: -- → P1
Target Milestone: --- → mozilla1.0

    
    

    
  


  
That black border is ugly, but a lost menu isn't anything to laugh at.

    
    

    
  
*** Bug 132135 has been marked as a duplicate of this bug. ***

    
    

    
  
This may sound strange but even when I get the build from 2002-03-19-10-trunk it 
still says 2002031903 in the title bar.  I checked my download process and 
deleted everything, but still seeing 2002031903.  Is something strange going on 
or just me.  Could that be why the installer works, but zips don't?

Marc, to answer your question yes with the early morning build I was seeing the 
same as the attachment you posted in attachment #74985 [details].  We actually had a 
midair collision when i was trying to post my comment and you were adding yours 
along with the attachment.

I reposted then realized yours was the same as mine.




    
    

    
  
Alan: You're seeing bug 81344 and/or bug 36920. The "correct" Build ID is listed
in \bin\components\master.ini (AFAIK).

    
    

    
  
this isn't specific to the build system, i just verified this with a win32 gmake
build.

I'm starting to think that the installer is doing more chrome initialization and
something is keeping the .zip files from just working. I'll try and see if i can
run a mozilla binary from a built tree and see if that helps anything.

    
    

    
  
Leaf, the problem is that up until today, *some* of the ZIP builds worked okay.
 Usually the early morning ones were fine, and the later afternoon ones were
hosed.  If it were a general problem of installer vs zip builds, I would think
that all the zip builds to be hosed.  And the it's definitely true that the
"good" builds don't seem to have embed.jar in them.

    
    

    
  
ok, so this basically makes using a nightly build impossible. I've turned off my
auto-update batch script because the new zipped nightlies are unuseable. Last
time I checked that made this bug nsdogfood. (Haven't had to use that keyword in
quite a while)

Is embed.jar the culprit in all of the cases here? Why is it being included in
the first place? And if this is an issue with screwed-up files included in the
build, shouldn't this be moved from XPApps to BuildConfig or something similar?

I don't see any reason why embed.jar would be built in builds from the 18th, but
not from builds on the 17th. Bonsai reports some work in embedding on the 14th
and some stuff here and there after that, but nothing really obvious stands out
as to causing this bug.

If the "strange UI in 0.9.9" is the same issue, then there is an underlying
problem that has existed for longer than we think. I have asked to reporter of
that bug to see if embed.jar is present in his hosed 0.9.9 build to see if that
is the case.
Keywords: mozilla1.0, 
          
            nsdogfood

    
    

    
  
*** Bug 132260 has been marked as a duplicate of this bug. ***

    
    

    
  
I just downloaded:

http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
dated 20-Mar-2002 07:43 -- build id: 2002032003

And it no longer has this problem.  The last few zipped nightlies I've 
downloaded have had the problem described in this bug.  This is Win2k.


    
    

    
  
*** Bug 132314 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 132260 has been marked as a duplicate of this bug. ***

    
    

    
  
Same again today. 2002-03-20-05-trunk has no embed.jar in installed-chrome.txt,
2002-03-20-09-trunk does. Same results.

Mike Young: There was only one win32 build on the 17th, which might explain the
results from that day. Every day that has had two win32 builds since the 14th
has resulted in the earlier zip being ok and the later being hosed.

    
    

    
  
Sorry, the later today is in 2002-03-20-10-trunk, not -09- as I stated above.


    
    

    
  
sounds like a depend and installer combo problem since the 8am builds are
showing it but the 3am arent.  Since this is a non-installer build this is
nsbeta1- and not nsdogfood so minusing and removing nsdogfood keyword.  Reducing
severity since leaf has more critical nsbeta1+ bugs on his plate to get done
before Tuesday.
Severity: blocker → normal
Keywords: nsbeta1, 
          
            nsdogfood → nsbeta1-
Priority: P1 → P3

    
    

    
  
Maybe something didn't get a NO_JAR_AUTO_REG=1 in embedding and should have. The
auto registering jar file changes from bug 129456 seems to be when this started
happening.


    
    

    
  
Taking. Renominating.  

I can't duplicate the problem in my builds but the screenshots look like
problems that I ran into while developing the original auto-reg patch.  However,
I'm wondering why we weren't seeing this problem before as the auto-reg patch
only removed the explicit registration of the embed-sample.jar entries.  It
didn't add any.

At http://bugzilla.mozilla.org/show_bug.cgi?id=131461#c9 , mkaply makes the
observation that we had a classic/modern mismatch before the changes from bug
129456 .

Assignee: leaf → seawood
Status: ASSIGNED → NEW
Keywords: nsbeta1- → nsbeta1
Priority: P3 → P1

    
    

    
  
Bah & fie.  make -C embedding/config is part of the nightly automation but not
part of the default build.  When make-jars.pl is called there on the generated
embed jar.mn, it's autoregistering the chrome entries.  Patch coming up.


Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 75347 [details] [diff] [review]
don't autoreg generated embedding jar files

r=bryner

        Attachment #75347 -
        Flags: review+

    
    

    
  
Patch checked in.

Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Blocks: 131351

    
    

    
  
*** Bug 132392 has been marked as a duplicate of this bug. ***

    
    

    
  
verified on windows 98 (commercial netscape build: 2002-03-26-05-TRUNK)
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: