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.

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

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.

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

between which builds did this regress?

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

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

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.

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.

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?

Tracy, that seems reasonable. Lowering severity. Let's get this landed quickly, though.

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.

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.

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

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

Comment on attachment 168713 [details] [diff] [review] Workaround V1.1 File a bug for fixing the root cause that we're wallpapering over here.

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.

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

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+

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