Open Bug 42952 Opened 24 years ago Updated 2 years ago

On startup, should load all chrome before Net content

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

Future

People

(Reporter: mpt, Unassigned)

Details

(Keywords: helpwanted)

Attachments

(2 files)

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?
my best guess is networking. However, this could be a UI thing as well. Asa, any
thoughts?
over to XPApps first
Assignee: asa → ben
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
hm, my guess is this is a skins issue. next? ;)
Component: XP Apps: GUI Features → Skinability
QA Contact: sairuh → BlakeR1234
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
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.
OS: Mac System 9.0 → All
Hardware: Macintosh → All
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).
Pretriage of skinnability bugs, really nice to have, but sounds too complex to 
fix for beta1, marking nsbeta1-
Keywords: nsbeta1-
Mozilla1.0 nomination.
Keywords: mozilla1.0
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
CCing Pavlov and Hewitt after discussing this with Saari.
QA Contact: blakeross → pmac
Mass move skinability bugs to nobody@mozilla.org, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted
This doesn't seem very Skinability to me. --> XP Toolkit/Widgets.
Assignee: nobody → trudelle
Component: Skinability → XP Toolkit/Widgets
QA Contact: pmac → jrgm
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani
mpt: does this still happen?
I don't know -- it's been months since I used Mozilla, and two years since I 
used an authenticating proxy.

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

Assignee: samir_bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: