274481 - Domain name mismatch dialog missing all buttons

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Tracy Walker [:tracy]]

seen on Windows Fx trunk build 2004-12-13-07-trunk

-goto https://verisign.com

test results: The domain name mismatch dialog appears as expected. But the
dialog is missing the second paragaph of text and all four buttons: View
Certificate, Okay, Cancel and Help. The only way to dimiss the dialog is with
the [X].  This blocks viewing cert and the expected web page.

expected results: The dialog is complete.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

I see this too (linux/gtk2/metacity), but resizing the dialog shows all the buttons.

Comment 2

[Tracy Walker [:tracy]]

I didn't see this on redhat linux 8.  The dialog came up complete.
It was also okay on Mac.
On windows the dialog is not resizable.

Comment 3

[Darin Fisher]

I'm able to reproduce this using a debug CVS build pulled this morning.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

between which builds did this regress?

Comment 5

[Stefan Borggraefe]

(In reply to comment #4)
> between which builds did this regress?

I'm sure this is a regression from my patch for bug 251991. This seems to
trigger a bug in Toolkit's dialog.xml. XPFE doesn't have this bug. I'm currently
trying to find a good fix for Toolkit.

When I comment out this part in dialog.xml

            // hide/show the buttons we want
            for (dlgtype in buttons) 
              buttons[dlgtype].hidden = !shown[dlgtype];

the dialog has the correct size (but of course it only has the default buttons
then).

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, sorry. then I'm seeing a different bug in comment 1. undoing my OS change.

Comment 7

[Stefan Borggraefe]

Attachment: Workaround

Some news:

- this bug is *not* caused by Toolkit's dialog.xml directly. I copied the XPFE
version of this file into the toolkit/ directory and the bug was still there.

- I verified that backing out bug 251991 fixes this bug.

- As an alternative the attached patch is a workaround for this bug. I really
need some sleep now and I won't be able to further investigate this bug for the
next 18 hours. So if noone else finds a better fix and this blocker needs to be
cleared, you could either take this workaround for now or back out the patch
for bug 251991.

- I do see this bug with FF on Linux. So OS "All" was correct.

Comment 8

[Stefan Borggraefe]

My compilation of a fresh Seamonkey build just finished and I still don't see
this bug with it. Only with my FF build. Both builds are Linux Gtk2 debug builds.

Comment 9

[Tracy Walker [:tracy]]

Stefan, just to confirm; I didn't see this on Seamonkey builds from 12/13 on any
platform. 

Asa, since there is a simple patch/workaround forth coming, we probably no
longer need to hold the tree for this.  What do you think?

Comment 10

[Asa Dotzler [:asa]]

Tracy, that seems reasonable. Lowering severity.

Let's get this landed quickly, though. 

Comment 11

[[e-mail]]

Comment on attachment 168674 [details] [diff] [review]
Workaround

I think 18em is too big, it leaves a noticable gap between the text and the
buttons. I tried values between 8em and 16em and they all seem to work, oddly
the bug cuts in when the height is less than 8em. Someone needs to test this
with large fonts to see what sort of range of heights works.

Comment 12

[Stefan Borggraefe]

Attachment: Workaround V1.1

So this bug isn't Firefox specific, but seems to depend on the used font size
(and other theme specific things?). When I use a very small font (7pt) in
Seamonkey, I see this bug there too.

Neil: I tested several font sizes to see which height is necessary to
circumvent this bug:

UI Font size  Needed height
--------------------------------------
20 pt	      no height rule necessary
11 pt	       7 em
7 pt	       9 em
5 pt	      12 em

The new patch uses 12em. Since 7pt is hardly readable as a UI font already,
12em should be a safe value.

Requesting r and sr this time, so this patch can land faster. Should be ok
given the simplicity of this workaround.

Comment 13

[Hermann Schwab]

(In reply to comment #12)
 
> So this bug isn't Firefox specific, but seems to depend on the used font size
> (and other theme specific things?). When I use a very small font (7pt) in
> Seamonkey, I see this bug there too.

Seems to have caused Bug 274579 https://sergas.es/ on Seamonkey Trunk
Maybe somebody from here can dupe that bug or put it into the right component.

Security Error: Domain Name Mismatch

The message doesn´t have buttons to accept or cancel, if you close the message
box, an empty page is loaded.

Comment 14

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 15

[[e-mail]]

Comment on attachment 168713 [details] [diff] [review]
Workaround V1.1

File a bug for fixing the root cause that we're wallpapering over here.

Comment 16

[Stefan Borggraefe]

Fix checked in.

Bug 274703 is the follow-up bug to fix the underlying cause. I'm moving this bug
to PSM/Client Library, because this is the component where the wallpaper was
applied.

Comment 17

[Stefan Borggraefe]

Somehow bugzilla ate Neil's r+ flag... I filed bug 274704 about this.

Comment 18

[Bill Gianopoulos [:WG9s]]

Verified fixed with latest Beast build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041215
Firefox/1.0+

Comment 19

[Stefan Borggraefe]

I backed out the workaround again, because bug 274703 fixed the root-cause of
this bug.