55838 - Security warning dialog box is partially missing

Status: VERIFIED DUPLICATE of bug 62955

(SeaMonkey :: Themes, defect, P1)

Description

[Patty Mac]

G4-Mac System 9.0
Build (2000-10-06-13-MN6)

Steps to reproduce:

1. Launch Netsape 6 (Classic skin is the default).
2. Go to www.home.netscape.com
3. Type the stock quote for AOL in the rectange box showing "Business Market
   Center Stock quotes, etc...."
4. The "Sercurity waring" dialog box partially displays. Unable to see
   the cancel and Ok button. I nominate for rtm++ because you can not 
   do anything, should re-boot the system. Screen shot will attach.

Comment 1

[Patty Mac]

Attachment: screen shot for 'security waring dialog box'

Comment 2

[Patty Mac]

Attachment: screenshot for the 'security waring dialog box'

Comment 3

[Doron Rosenberg (IBM)]

over to themes, keyword magic (this is dogfood)

Comment 4

[hangas]

Sending to Andrew, marking rtm need info

Comment 5

[andreww]

This dialog must be created via C++ - as I cannot find any security alert dialog 
xul.  Adding dougt as CC as pavlov said he might have some insight.

Doug, is there a way to make that dialog taller?

Comment 6

[Doug Turner (:dougt)]

we use alert/confirm.  It is a bug in the toolkit.

Comment 7

[andreww]

Hangas asked me to cc marketing on this bug.

Comment 8

[andreww]

I've been trying just about everything I can think of as a XUL and JS developer, 
and I've spent some time talking with danm about this and I'm totally puzzled.  
There seems to be something about classic skin that is either causing a race 
condition where the window is sizing before the content is in, or something to do 
with the window's height.  This is a fairly convoluted bug.  I'm not confident of 
finding a solution by tomorrow...

Comment 9

[andreww]

Trying some possible tests suggested by hyatt

Comment 10

[andreww]

I can resize the window, but it breaks every other alert dialog. Still fishing

Comment 11

[Jim Roskind]

Even though you can't see the "OK", won't pressing enter trigger it?  Worst
case, doesn't a "tab" move the "OK" to being (invisibly) highlighted, and then
you can just press "enter?"
How bad is the hang?  Does the above work-around it?

Comment 12

[andreww]

There is no hang. You can press enter to go on or escape to not.  It behaves just 
like a normal dialog, it's just that you cant seen the ok and cancel buttons.

Comment 13

[Jim Roskind]

Marking dogfood-minus, since "hitting return" is sufficent (rather than a reboot).

Adding Hyatt on the off chance that he'll spot the race condition issue that you
are corcerned about.

Comment 14

[Stephen P. Morse]

See also bug 57211 which appears to be a dup of this bug.  Also mac-only, also 
classic-skin only, also a clipping of a dialog.  That bug is about the cookie 
warning dialog, so it is more than just the security dialog that is affected.

Comment 15

[andreww]

After much trial and error I'm slowly narrowing this down. So far the problem 
must be in formatting.css.
Now I'm removing half of that file, etc. etc.

Getting close!

Comment 16

[andreww]

Attachment: fix for formatting.css

Comment 17

[andreww]

there are multiple bugs here but the workaround fix is to put a transparent 
border around the html widget so that it reflows and get's it's proper height.

It's a one line fix which will fix 3 bugs.

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

r=[e-mail]

Comment 19

[andreww]

sr=[e-mail]

Comment 20

[andreww]

This will also fix 56614, and 57211.

Comment 21

[andreww]

fix ready

Comment 22

[andreww]

ok a "real" fix is to change the html tag to a box tag in commonDialog.xul so 
that the illegal case of having an html element inside and html element doesnt 
occur.

Making new patch

Comment 23

[andreww]

Attachment: patch to commonDialog.xul

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

r=[e-mail] for the real fix. 

Comment 25

[andreww]

sr=hangas for real fix.

Comment 26

[andreww]

Checked in real fix to trunk.

Comment 27

[andreww]

Talked with eric vaughan about the bug - and other than saying that an html 
element inside an html element is "illegal" he wasnt able to offer any 
explaination as to why mac classic would have this problem over any other 
version/skin.  He said that if we were to present to him a simple test case of 
the problem he could make an effort to fix it. :)

Comment 28

[John Unruh]

Verified with the Mac commercial trunk 102404 build. Adding vbranch keyword.

Comment 29

[Patty Mac]

Verified on all platforms (Build: 2000-10-24-06-MTrunk)

Comment 30

[John Unruh]

Still busted in the Mac 10/24 branch build.

Comment 31

[andreww]

Reopening - this wasnt supposed to be marked fixed yet. Ahem

PDT wants us to stage the fix on the tip and if it's ok then check it in to the 
branch.  Please leave open so PDT can see it :)

Comment 32

[Patty Mac]

Andrew, I did not mark "fixed" though.

Comment 33

[hangas]

Attachment: jglick testing of this patch

Comment 34

[selmer (gone)]

rtm++

Comment 35

[andreww]

Patty you were doing the right thing. Thanks!
Checked fix into branch. Crossing fingers :)

Comment 36

[John Unruh]

*** Bug 54398 has been marked as a duplicate of this bug. ***

Comment 37

[John Unruh]

Verified. fixed in Wed's branch build

Comment 38

[Patty Mac]

Verified ok on Mac (2000-11-27-08-Mtrunk).

Comment 39

[John Unruh]

Reopening. This bug is back in the 12/18 Mozilla build.

Comment 40

[John Unruh]

Setting to critical

Comment 41

[John Unruh]

*** This bug has been marked as a duplicate of 62955 ***

Comment 42

[Stephen Walker]

vrfy dup