Closed Bug 51013 Opened 24 years ago Closed 24 years ago

Initial NS6 page looks crappy, horrible first impression

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: greggl)

References

(
URL
)

Details

(Keywords: polish, Whiteboard: [PDTP2][nsbeta3+])

Attachments

(6 files)

It looked good in PR2 (M17)
76.31 KB, image/jpeg
Details
Now it looks crappy. :-(
81.71 KB, image/jpeg
Details
A FIXED version of the initial start page
25.84 KB, text/html
Details
A screen shot of the attached FIXED page running in the current nightly build.
95.27 KB, image/jpeg
Details
Screenshot of fixed page in PR2
77.55 KB, image/jpeg
Details
screenshot of page breaking in PR2
31.16 KB, image/gif
Details 
when NS6 starts up, it loads:
 http://home.netscape.com/browsers/6/su_setup.html

This page is totally scrunched up at the top of the window, doesn't ever
correctly layout, and generally makes us look like complete buffoons.

Not sure who should get this, but if we can't fix this layout bug, we should
pull this URL as the first one that users see and send them to the homepage.
waterson, i know this shouldn't go to you, but the default layout owner is
clayton, and i really don't think he'll know how to triage. I'll leave this in
your capable hands to redirect.

Please, let's not ship B3 with this as the default page. Are you there, god?
It's me Margaret
Keywords: correctness, nsbeta3, polish, rtm
OS: Mac System 8.5 → Mac System 9.0
This page also pegs the cpu, as described in bug 36785. All in all, a nearly
worst-case first impression.
BLAH!

is nothing being done on this bug? we're a week from b3 and no one has even 
attempted triage. cc'ing jar.

JohnG: Do you know who is handling this page over at Netcenter?  I had a sense
that it came from somewhere over here... I think I may have seen the demo on
your screen for beta 2 (when the page was working better).

Who should be handling the repair of the page?

Thanks,
Jim
sorry, i've been gone for a week. i'll take a look at it and try to minimize the 
HTML.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18

    
    

    
  


  

    
    

    
  
It would be a real shame if we couldn't get this page working again.

How did we break it so badly?


    
    

    
  
Spam some layout folks.


    
    

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

    
    

    
  
suggesting raising the priority on this to P1 or P2 so it stays on the nsbeta3+ 
radar...

    
    

    
  
Investigated this a little bit. Netcenter is using "document.height" to
determine the height of the document, and we're now returning zero. This change
in behavior was introduced when I fixed bug 44480, which was to use the <body>
element's frame for document.[height|width], not the <html> element's frame.

IMO, Netcenter should be using "window.innerHeight", not "document.height" here:
*all* of the content that they have is absolutely positioned, so the flowed
document really *does* have no height.

(FWIW, "sed 's/document.height/window.innerHeight/g' su_setup.html" fixes the
problem. They should probably also be using window.innerWidth instead of
document.width.)

cc'ing others more familiar with legacy behavior than I am: I believe this bug
is INVALID and the HTML needs to be fixed...


    
    

    
  
er, the JS embedded in the HTML needs to be fixed!


    
  
OS: Mac System 9.0 → All
Hardware: Macintosh → All

    
    

    
  
marking invalid to prompt a reaction.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID

    
    

    
  
yes, the html needs to be fixed, but we have to make sure it's fixed before we 
ship B3. If this bug is closed, who is on the hook to fix it? I know that it will 
just slip through the cracks (again). 

Status: RESOLVED → REOPENED
Resolution: INVALID → ---

    
    

    
  
Updated the status whiteboard with the current status of the bug.

Whiteboard: [nsbeta3+] → [nsbeta3+] NEED TO FIX HTML ON THAT PAGE

    
    

    
  
JohnG: Who should we assign this to in Netcenter to get this taken care of?

    
    

    
  
reassigning to johng for now...

Assignee: waterson → johng
Status: REOPENED → NEW

    
    

    
  
Adding "evangwanted" keyword :P :-)

(Well, the web page needs to be fixed, doesn't it?)

Keywords: evangwanted

    
    

    
  
The dynamic content of this page also shows how bad we are at handling that while 
not eating huge amounts of CPU time. Sitting on that page on Mac causes the watch 
cursor to show up, which means that we're away from the main event look for long 
periods of time. See bug 50356


    
    

    
  
page STILL not fixed, although it only takes ONE sed script line to do it.
Moving up to Priority 1 to get someone's attention.

Next thing I'll do is grab the web page html, do the sed script command on it,
and attach it to this bug. And even THAT probably won't be enough to get this
bug fixed. :P

Priority: P3 → P1
Whiteboard: [nsbeta3+] NEED TO FIX HTML ON THAT PAGE → [nsbeta3+] NEED TO FIX HTML ON THAT PAGE, a *15 SECOND* change!

    
    

    
  
The black spot and the missing arrows in the screen shot are due to missing
images. (and I don't think I can fix that with the bugzilla attachment system
the way that it is).

There is a javascript bug in mozilla where the start procedure in the javascript
isn't being called if the page is loaded from the cache, but hitting
SHIFT-Reload will cause the javascript procedure to be called and then the page
will be laid out properly.


    
  
Whiteboard: [nsbeta3+] NEED TO FIX HTML ON THAT PAGE, a *15 SECOND* change! → [nsbeta3+] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG!

    
    

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

    
    

    
  
hey johng, what's the status on this? we'd look awfully foolish if we couldn't
even display our own start page...



    
    

    
  
Removing `evangwanted', it does not make sense in this context.
Keywords: evangwanted

    
    

    
  
Folks at Netcenter working on this. Reassigning to greggl, cc'ing chrisn.

Fix will be ready for rtm, not required to be ready by pr3.

Assignee: johng → greggl

    
    

    
  
wait, we have a fix today, do we not?


    
    

    
  
It would be Very Nice to get this content pushed before PR3.  Can we get it 
scheduled to push RSN, and not wait?  I'm sure it is not worth a special "push" 
in Netcenter, but I'm guessing they do at least one a week.

    
    

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

    
  
Keywords: netcenter

    
    

    
  
see also bugscape 2163


    
    

    
  
PDT:  We hope Netcenter would rank this highly.  For CPD: P2 for PR3, must fix
for RTM.  It appears that we need Netcenter help to effect a change in the html
page itself.  This bug contains a fix.

Priority: P1 → P2
Whiteboard: [nsbeta3+] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG! → [nsbeta3+] [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG!

    
    

    
  
Seriously, is it THAT hard to copy ONE attached HTML file out to your servers?

Come on. PR3 is a PUBLIC BETA. The page in its current state makes us look VERY
VERY STUPID!


    
    

    
  
jce2: we appreciate your input on this bug. However, you have to understand that 
there are internal administrative and political processes that make it non-
trivial to update web pages in another section of the company. This will happen, 
it might just take some time.


    
    

    
  
Can we mirror this page on mozilla servers by any chance? It may be easier to
change the code to point to the fixed page on a mozilla server then to get
netcenter to fix the page on their server! (how screwed up is that?)


    
    

    
  
Bugscape bug 2545 also covers this.


    
    

    
  
Netcenter Production is making the content changes via chrisn and file changes 
via jce2.  Problem that we are seeing now is that the new version of the page 
breaks in N6 PR2.  So at this point, we are going to wait to push the updated 
/su_setup.html page out until the rest of the PR3 pages are going out.  Unless 
of course we have a fix that will work for both PR2 and PR3.  In the future we 
would like to add a sniff scrip....so if the page is accessed from an older N6 
product, it will redirect to the download page to get the latest N6 version.
Status: NEW → ASSIGNED

    
    

    
  
Hmm, let me think for a little bit. I think I could add a little javascript code
that sniffs internally about PR2 vs PR3.

When does PR2's timebomb go off?


    
    

    
  
Umm, my attached page doesn't break in NS6 PR2 on my system (Windows 2000). I've
attached a screenshot of it rendering in PR2. Is there something obvious I'm
missing in that screenshot? Could you attach a screenshot of it rendering
improperly in your instance of PR2?


    
    

    
  
AHA! Try loading that attachment again, then hit "Shift-reload".

That bad rendering occurs when you have that page in the cache (because the
javascript isn't firing). However, it does not occur when you load it upon
startup, or when you force a reload not from the cache.


    
    

    
  
ok, actually, you also have to do "Preferences->advanced->Cache->Compare network
version with cached version every time". to make shift-reload work.

(But if you don't do that, then shift-reload doesn't work in many other places
you would think that it should work.)

Anyways, we're only planning on showing this to the user the FIRST time he opens
the browser after an installation, right? If so, then we won't run into any of
these cache bugs anyways. I've also found that if I set this as my home page,
then the javascript fires properly upon opening the browser.


    
    

    
  
Yes, we are only planning on showing this upon start-up....however, it will 
always be accessible from the chrome under Help > What's New in Netscape 6.  
Will that affect it?

    
    

    
  
It might, but we can easily tell the chrome to do the equivilent of a
"shift-reload" when loading that URI.


    
    

    
  
jce2: is there a bug on file for javascript not firing when you reload from the
cache, or was that fixed already (long ago, even)?

/be

    
    

    
  
Brandon: That "bug" still exists in today's nightly build. I didn't know that it
existed in the PR2 build because I've never run into it on PR2 (then again, I
really didn't USE pr2 that much).


    
    

    
  
To clarify, this page has the following javascript function:

function start() { resizeWindow(); q1(); }

and q1 is the function that moves all the elements to their correct locations.
If start() isn't called when the page is loaded, then you get what you see in
the "breaking in PR2" screenshot. However, once start() is called, the page will
always render properly. Oh, and that is called by:

<body onload="start()" bgcolor="#ffffff" text="white">

in the bottom html.


    
    

    
  
If this is really a cache interaction, and we only show the page the first time, 
then real users probably won't see the bug. Marking nsbeta3- on that argument. 
Please correct me if I'm wrong. The bug already has the RTM keyword. If it's 
really the cache, then is Gregg the right owner?
Whiteboard: [nsbeta3+] [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG! → [nsbeta3-] [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG!

    
    

    
  
I would agree that I would not be the right owner for that type of problem.

    
    

    
  
WOAH!!! WAIT WAIT WAIT WAIT WAIT!!!

Phil: *EVERY* user will see the current (if they haven't propagated my fix)
start page render BADLY. The page that was sitting
on netcenter relies on broken behaviour that existed in PR2 and was FIXED in the
drive for beta3. Repeat, the current (non-fixed)
page will render HORRIBLY for EVERYONE using PR3, ALL of the time.

I have FIXED that page so it no longer relies on broken behaviour and attached
that page to this bug. That page will
ALWAYS render correctly on startup, or in cases when it doesn't get put into the
cache, and it can be made
to render correctly in cases where the javascript does not fire properly simply
by hitting "Shift-reload".

Therefore, although my fixed page still exhibits buggy behaviour in a few cases,
due to a mozilla cache bug, it
will ALWAYS render properly on startup, which is our primary concern. Not fixing
this bug (or propagating my fix),
will result in a page that will ALWAYS render *incorrectly* on startup (and in
every OTHER situation as well, because
the javascript is invalid).

Removing nsbeta3- for reconsideration.







Whiteboard: [nsbeta3-] [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG! → [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG!

    
    

    
  
adding myself to the cc list.  

I'm eager to see it fixed.  this page gives the user such a horrible first 
experience.

can we get netcenter to use the fixed version (provided by jce2)?

    
    

    
  
actually, the fix version provided by jce2 still doesn't work right on my linux 
build.

I'd suggest going to a simpler start page altogether until the real bug is 
fixed.

sending mail to the pdt for reconsideration.

    
    

    
  
> the current (non-fixed) page will render HORRIBLY for EVERYONE using PR3, ALL of
> the time

Ok, thanks for the clarification. Gregg, where do you guys stand with this? Can
you push a version of the page which works with PR3?


    
    

    
  
The latest from Netcenter is this.  The Production Specialist is having trouble 
getting it to work with the latest PR3 build.  She is not trained to work on 
this type of page, nor is anyone in Netcenter.  Her manager, Paul Bloom 
suggested the following:

"I vote we go with Chris' plan b. Let's make this an image map or chop it up and 
put it into html for pr3.  Then look at a real fix that we can properly QA for 
rtm. Chris, can you run this past the powers that be on your side?  The question 
is, how long before rtm will we freeze the bits so we can build and test on what 
is close to the final build? Paul"

Chris Nalls then wrote back:  "This is fine. Michael LaGuardia knows about, 
approves of and actually SUGGESTED this fix!" 

So, this is what I am assuming we are going to do.  michaell or chrisn or phil, 
can we get final confirmation on this?

    
    

    
  
Gregg, your B3 suggestion sounds good to me -- let's do it. With respect to your
question:

> how long before rtm will we freeze the bits so we can build and test on what
> is close to the final build?

We are freezing for RTM on Monday 10/16, and baking until it's done.


    
    

    
  
Go ahead with plan B.


    
    

    
  
Actually, I would also prefer that the layout is done by HTML instead of by
Javascript.

I don't care if you use my fix or not AS LONG AS the initial start page for
netscape is NOT OBVIOUSLY BROKEN!


    
    

    
  
greggl: is somebody (you?) fixing the html for this page? if nobody else is,
then please reassign to me -- i can do it (i'm a webdesigner in a past life, you
might say).

updating status whiteboard, because proposed fix doesn't work. also, this ought
to be approved for rtm...

Whiteboard: [PDTP2] NEED TO FIX HTML ON THAT PAGE, FIXED VERSION ATTACHED TO BUG! → [PDTP2]

    
    

    
  
We should also file a bug on <Body OnLoad> as it relates to cached pages,
because this is why my proposed fix doesn't work properly. (Although the simple
test case in a very early bug DOES work properly).



    
    

    
  
jce2: i'm not sure what the problem you're referring to is... is onLoad firing
too early or something? whatever -- anyway, yes, please file that other bug. thanks!


    
    

    
  
dr: see jce2's comments under "Additional Comments From jce2@po.cwru.edu 
2000-09-26 18:00".

/be

    
  
Blocks: 54594

    
    

    
  
I just installed b3 on win98, activated, and got this page. It looks like shit,
is unreadable because the text is all scrunched up in the corner, and it eats
all my cpu time. Marking nsbeta3+.

Whiteboard: [PDTP2] → [PDTP2][nsbeta3+]

    
    

    
  
Folks...This page is getting fixed by Netcenter.  It's in production Ticket
#11483 http://ticketmon.mcom.com/ticketmonster/
and should be done later today and pushed tonight (Friday night).



    
    

    
  
I just tried out the new page (http://kick:1280/browsers/6/su_setup.html) it
works and looks great on win32 and linux.

can't wait to see it go live.



    
    

    
  
Gregg: So I notice y'all went ahead with plan B. (It's one big imagemap, for
those of you outside the firewall). So that's fine, of course, so that we don't
look stupid when PR3 ships, but I'm just a tiny bit wary of your comments on
ticketmonster (http://ticketmon.mcom.com/ticketmonster/view.html?ticket=11483).

You claim that "due to multiple bugs," we needed to do this, and to disregard
the submitted HTML file. I just wanted to make this clear that there's only one
bug that makes the page layout improperly (jce2's onload bug), and it can be
worked around by using HTML and javascript in a much less unorthodox manner than
before. What I'm referring to is that it's /really/ odd to layout the entire
page in Javascript, rather than letting Gecko do most of the work and only
having the dynamic parts Javascripted. That's Barbara Shepard's business,
though. Regardless of unorthodox design techniques, I also want to make it clear
than jce2's attached fix should work fine once the onload bug is fixed.

Apologies if I'm preaching to the choir -- I don't mean to patronize anybody --
but I do want to make sure this gets fixed the *right* way for RTM. I'm sure
we'd rather be showcasing the slick new layout engine rather than letting users
sit and wait for one big image to download :)


    
    

    
  
It's now October 2nd and the file hasn't been pushed out onto the production
server(s) yet. Are we going to wait until RIGHT at the date of releasing PR3?
IMO, that's a bad decision, we should have a day of smoketest with the fixed
homepage if possible.


    
    

    
  
Update on page:  QA has signed off on it.  The page is being committed as I 
write this, it should be live within the hour.

Open Issue:  The sub-pages have screen shots from the PR2 UI.  We will update 
the images as soon as we can.  Wanted to get this out live first.

    
    

    
  
Old page still is up on this, I thought this went live?

    
    

    
  
slight miscommunication....the page is live now.

    
    

    
  
Marking Fixed, because the first page no longer looks crappy. However, I hope
that we'll come up with a more advanced page for RTM that does show the advanced
capabilities of Gecko.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Marking verfied.

Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: