TestGtkEmbed pop up dialogues missing text & text entry fields

VERIFIED FIXED in mozilla0.9.7

Status

Core Graveyard
Embedding: GTK Widget
--
blocker
VERIFIED FIXED
16 years ago
6 years ago

People

(Reporter: tracy, Assigned: Dan M)

Tracking

({smoketest})

Trunk
mozilla0.9.7
x86
Linux
smoketest

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

16 years ago
Keywords: smoketest
over to danm
Assignee: blizzard → danm
(Assignee)

Comment 2

16 years ago
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.
(Assignee)

Comment 3

16 years ago
  ...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

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

Comment 5

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

Comment 6

16 years ago
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.
(Assignee)

Comment 8

16 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 9

16 years ago
.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.7

Comment 10

16 years ago
yes, the backout fixes this.  verifying.
Status: RESOLVED → VERIFIED
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.