Domain name mismatch dialog missing all buttons

VERIFIED FIXED

Status

Core Graveyard
Security: UI
--
critical
VERIFIED FIXED
14 years ago
2 years ago

People

(Reporter: tracy, Assigned: Blake Ross)

Tracking

({regression, smoketest})

Other Branch
x86
All
regression, smoketest
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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.
OS: Windows XP → All
(Reporter)

Comment 2

14 years ago
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

14 years ago
I'm able to reproduce this using a debug CVS build pulled this morning.
between which builds did this regress?

Comment 5

14 years ago
(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).
Depends on: 251991
hm, sorry. then I'm seeing a different bug in comment 1. undoing my OS change.
OS: All → Windows XP

Comment 7

14 years ago
Created attachment 168674 [details] [diff] [review]
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.
Attachment #168674 - Flags: superreview?(jst)
Attachment #168674 - Flags: review?(neil.parkwaycc.co.uk)

Updated

14 years ago
OS: Windows XP → All

Comment 8

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

Comment 9

14 years ago
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

14 years ago
Tracy, that seems reasonable. Lowering severity.

Let's get this landed quickly, though. 
Severity: blocker → critical

Comment 11

14 years ago
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

14 years ago
Created attachment 168713 [details] [diff] [review]
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.
Attachment #168674 - Attachment is obsolete: true
Attachment #168713 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #168713 - Flags: review?(neil.parkwaycc.co.uk)

Updated

14 years ago
Attachment #168674 - Flags: superreview?(jst)
Attachment #168674 - Flags: review?(neil.parkwaycc.co.uk)

Comment 13

14 years ago
(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 15

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

File a bug for fixing the root cause that we're wallpapering over here.
Attachment #168713 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #168713 - Flags: superreview+
Attachment #168713 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #168713 - Flags: review+

Comment 16

14 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Component: General → Client Library
Flags: review+
Product: Firefox → PSM
Resolution: --- → FIXED
Version: Trunk → unspecified

Comment 17

14 years ago
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+
Status: RESOLVED → VERIFIED

Comment 19

14 years ago
I backed out the workaround again, because bug 274703 fixed the root-cause of
this bug.
Depends on: 274703

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.