Initial NS6 page looks crappy, horrible first impression

VERIFIED FIXED in M18

Status

()

Core
Layout
P2
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Gregg Landskov (gone))

Tracking

({polish})

Trunk
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDTP2][nsbeta3+], URL)

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
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

Comment 2

17 years ago
This page also pegs the cpu, as described in bug 36785. All in all, a nearly
worst-case first impression.

Comment 3

17 years ago
BLAH!
(Reporter)

Comment 4

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

Comment 5

17 years ago
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

Comment 6

17 years ago
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

Comment 7

17 years ago
Created attachment 14746 [details]
It looked good in PR2 (M17)

Comment 8

17 years ago
Created attachment 14748 [details]
Now it looks crappy. :-(

Comment 9

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

How did we break it so badly?

Comment 10

17 years ago
Spam some layout folks.

Comment 11

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

Comment 12

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

Comment 13

17 years ago
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...

Comment 14

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

Updated

17 years ago
OS: Mac System 9.0 → All
Hardware: Macintosh → All

Comment 15

17 years ago
marking invalid to prompt a reaction.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 16

17 years ago
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 → ---

Comment 17

17 years ago
Updated the status whiteboard with the current status of the bug.
Whiteboard: [nsbeta3+] → [nsbeta3+] NEED TO FIX HTML ON THAT PAGE

Comment 18

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

Comment 19

17 years ago
reassigning to johng for now...
Assignee: waterson → johng
Status: REOPENED → NEW

Comment 20

17 years ago
Adding "evangwanted" keyword :P :-)

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

Comment 21

17 years ago
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

Comment 22

17 years ago
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!

Comment 23

17 years ago
Created attachment 15255 [details]
A FIXED version of the initial start page

Comment 24

17 years ago
Created attachment 15256 [details]
A screen shot of the attached FIXED page running in the current nightly build.

Comment 25

17 years ago
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.

Updated

17 years ago
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!

Comment 26

17 years ago
*** 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...

Comment 28

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

Comment 29

17 years ago
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
(Reporter)

Comment 30

17 years ago
wait, we have a fix today, do we not?

Comment 31

17 years ago
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.

Comment 32

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

Updated

17 years ago
Keywords: netcenter

Comment 33

17 years ago
see also bugscape 2163

Comment 34

17 years ago
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!

Comment 35

17 years ago
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!

Comment 36

17 years ago
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.

Comment 37

17 years ago
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?)

Comment 38

17 years ago
Bugscape bug 2545 also covers this.
(Assignee)

Comment 39

17 years ago
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

Comment 40

17 years ago
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?

Comment 41

17 years ago
Created attachment 15575 [details]
Screenshot of fixed page in PR2

Comment 42

17 years ago
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?
(Assignee)

Comment 43

17 years ago
Created attachment 15578 [details]
screenshot of page breaking in PR2

Comment 44

17 years ago
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.

Comment 45

17 years ago
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.
(Assignee)

Comment 46

17 years ago
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?

Comment 47

17 years ago
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

Comment 49

17 years ago
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).

Comment 50

17 years ago
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.

Comment 51

17 years ago
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!
(Assignee)

Comment 52

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

Comment 53

17 years ago
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.

Comment 56

17 years ago
> 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?
(Assignee)

Comment 57

17 years ago
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?

Comment 58

17 years ago
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.

Comment 59

17 years ago
Go ahead with plan B.

Comment 60

17 years ago
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!

Comment 61

17 years ago
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]

Comment 62

17 years ago
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).

Comment 63

17 years ago
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

Updated

17 years ago
Blocks: 54594

Comment 65

17 years ago
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.

Comment 68

17 years ago
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 :)

Comment 69

17 years ago
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.
(Assignee)

Comment 70

17 years ago
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?
(Assignee)

Comment 72

17 years ago
slight miscommunication....the page is live now.

Comment 73

17 years ago
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
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 74

17 years ago
Marking verfied.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.