seen on linux TestGtkEmbed build 2001-11-16-06-trunk -attempt to log into a page with http auth the dialogue that pops up is missing text and form text entry fields the okay and cancel buttons are present, at least one can exit the dialogue. but it is impossible to login to the page. also pop up dialogues about security are also missing all text.
over to danm
status: the JS window property that carries the dialog configuration data is getting lost somewhere. It's a wrapped nsIDialogParamBlock object, and when it falls out in the window JS it's failing the QI. Seems to be happening only in TestGtkEmbed. I'm a little confused here.
...but if you close the broken auth dialog using the OS close widget, a new, perfectly functional auth dialog will pop up in its place. However, this works only if I remove the recently added (by me) call to GetAttention in commonDialog.js. Note that you don't get this effect by gutting the implementation of GetAttention in nsWidget, but only by removing the call in commonDialog.js. OK. I'm flailing here. As the duly dumped-on owner of this bug I'm starting a checkout by date to try to track down the problem. Woo hoo. This'll take several hours. Anyone with a brighter idea, feel free to chip in.
my 11/9 build works ok, trying a trunk build.
what url are people testing? let's at least agree on what is failing :-) I was trying to login at https://banking.wellsfargo.com/
I'm just using my local Apache. It worked yesterday morning. I'm plowing through yesterday's checkins (in a checkout/build kind of way) at the moment. Hour. Bug's life.
Is the inner loop that needs to be run to make sure that the chome is loaded before the content has finished loading returning early? I would suggest tracking the call to EmbedWindow::SetVisibility() and making sure that it has actually finished loading before the visibility is changed. Note that it checks the mChromeLoaded flag in there before causing the VISIBILITY signal to be sent, showing the window. We've had problems like this in the past and they were usually related to load events finishing too early.
Heck. Maybe I was just a goofball when I was last testing. After hours of trying to track down the specific change, it looks like it was my fix for bug 53345. Hmm. Backing it out. Seems to fix it.
yes, the backout fixes this. verifying.