42952 - On startup, should load all chrome before Net content

Status: NEW

(Core :: XUL, defect, P3)

Description

[Matthew T (active 1999-2002)]

Build: 2000060708, MacOS 9.0

To reproduce:
* Install Mozilla in an environment which requires a proxy authentication to
  connect to the Internet.
* Start Mozilla.

What should happen:
* The chrome appears.
* You are presented with a dialog asking for your user name and password.

What actually happens:
* Some of the chrome appears -- excluding bits of the sidebar, the toolbar button
  images, etc.
* You are presented with a dialog asking for your user name and password.
* For as long as the dialog remains open, the rest of the chrome does not appear.
  This looks rather silly.

Not sure where this should go ... XPApps? Networking? Threading?

Comment 1

[Matthew T (active 1999-2002)]

Attachment: screenshot of partly-dressed Mozilla waiting for my proxy info

Comment 2

[Doron Rosenberg (IBM)]

my best guess is networking. However, this could be a UI thing as well. Asa, any
thoughts?

Comment 3

[Asa Dotzler [:asa]]

over to XPApps first

Comment 4

[sairuh (rarely reading bugmail)]

hm, my guess is this is a skins issue. next? ;)

Comment 5

[Blake Ross]

Alright, alright I'll take it.  I don't know what I'm gonna do with it (I have 
no proxy server), but I'll hold on to it for now, I guess.  I don't think ben 
is going to fix this, though...really just a timing issue.  Maybe networking 
needs to wait a little longer before throwing the dialog?   cc'ing some random 
people for ideas on who should be doomed by this one

Comment 6

[Matthew T (active 1999-2002)]

Blake, another way to reproduce this would be to set your home page to a page 
which requires HTTP authentication.

> Maybe networking needs to wait a little longer before throwing the dialog

Given a skin of unknown complexity, how much longer is `a little longer'? :-) 
Also consider that some skins may be set up to fetch stuff from the Net 
themselves (e.g. a skin which changes color to suit the weather in your 
location); so just saying `all chrome:// first, all Net content later' isn't 
going to work either.

Comment 7

[Matthew T (active 1999-2002)]

Attachment: In the Classic skin, this also results in the borders of buttons (!) not appearing.

Comment 8

[Jacob Steenhagen]

Even more than a half drawn UI, what bothers me about the startup with an
Authenticating proxy is that the main content and Sidebar try to load at the
same time (assuming the sidebar is getting it's content from the web).  This
results in two different authentication boxes (and if the home page and sidebar
page are for different servers, the password has to be saved for both - see bug
59609).

My suggested startup order would be:
 * UI (everything in the chrome that's local)
 * Home Page (this is where proxy auth would take place)
 * Sidebar and web UI (don't necessarily have to wait until the home page is
done loading, just until a responce other than 407 is recieved).

Comment 9

[Paul Chen]

Pretriage of skinnability bugs, really nice to have, but sounds too complex to 
fix for beta1, marking nsbeta1-

Comment 10

[James Green]

Mozilla1.0 nomination.

Comment 11

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 12

[Matthew T (active 1999-2002)]

CCing Pavlov and Hewitt after discussing this with Saari.

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Mass move skinability bugs to [e-mail], helpwanted. 

Comment 14

[Matthew T (active 1999-2002)]

This doesn't seem very Skinability to me. --> XP Toolkit/Widgets.

Comment 15

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 16

[benc]

mpt: does this still happen?

Comment 17

[Matthew T (active 1999-2002)]

I don't know -- it's been months since I used Mozilla, and two years since I 
used an authenticating proxy.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.