If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

On startup, should load all chrome before Net content

NEW
Assigned to

Status

()

Core
XUL
P3
normal
18 years ago
12 years ago

People

(Reporter: Matthew Paul Thomas, Assigned: Samir Gehani)

Tracking

({helpwanted})

Trunk
Future
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

18 years ago
Created attachment 10337 [details]
screenshot of partly-dressed Mozilla waiting for my proxy info

Comment 2

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

Comment 3

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

Comment 5

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

Comment 6

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

Comment 7

17 years ago
Created attachment 13597 [details]
In the Classic skin, this also results in the borders of buttons (!) not appearing.

Updated

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

Comment 8

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

17 years ago
Pretriage of skinnability bugs, really nice to have, but sounds too complex to 
fix for beta1, marking nsbeta1-
Keywords: nsbeta1-

Comment 10

17 years ago
Mozilla1.0 nomination.
Keywords: mozilla1.0

Comment 11

17 years ago
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
(Reporter)

Comment 12

17 years ago
CCing Pavlov and Hewitt after discussing this with Saari.

Updated

17 years ago
QA Contact: blakeross → pmac
Mass move skinability bugs to nobody@mozilla.org, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted
(Reporter)

Comment 14

16 years ago
This doesn't seem very Skinability to me. --> XP Toolkit/Widgets.
Assignee: nobody → trudelle
Component: Skinability → XP Toolkit/Widgets
QA Contact: pmac → jrgm

Comment 15

15 years ago
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani

Comment 16

15 years ago
mpt: does this still happen?
(Reporter)

Comment 17

15 years ago
I don't know -- it's been months since I used Mozilla, and two years since I 
used an authenticating proxy.
You need to log in before you can comment on or make changes to this bug.