110494 - TestGtkEmbed pop up dialogues missing text & text entry fields

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect)

Description

[Tracy Walker [:tracy]]

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.

Comment 1

[Christopher Blizzard (:blizzard)]

over to danm

Comment 2

[Dan M]

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.

Comment 3

[Dan M]

  ...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.

Comment 4

[Chris McAfee]

my 11/9 build works ok, trying a trunk build.

Comment 5

[Chris McAfee]

what url are people testing?  let's at least agree on what is failing :-)
I was trying to login at https://banking.wellsfargo.com/

Comment 6

[Dan M]

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.

Comment 7

[Christopher Blizzard (:blizzard)]

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.

Comment 8

[Dan M]

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.

Comment 9

[Dan M]

.

Comment 10

[Chris McAfee]

yes, the backout fixes this.  verifying.