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.
Created attachment 13597 [details] In the Classic skin, this also results in the borders of buttons (!) not appearing.
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-
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
CCing Pavlov and Hewitt after discussing this with Saari.
Mass move skinability bugs to email@example.com, helpwanted.
Assignee: ben → nobody
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.
You need to log in before you can comment on or make changes to this bug.