If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Unknown content type dialog buttons don't look like buttons

VERIFIED FIXED in M15

Status

()

Core
XUL
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Akkana Peck, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: asap)

(Reporter)

Description

18 years ago
A few days ago, there was apparently a CSS change somewhere that removed the
borders from buttons; now they just look like any other label, with no border
and no mouseover highlighting, and there's no way to tell that they're buttons
unless you already know where the buttons are in a dialog.

I hate to think that we'll ship M12 like this (I predict we'll get a lot of
complaints).
(Reporter)

Comment 1

18 years ago
Cc'ing Kathy, who filed a similar bug to hyatt recently; that bug has been
closed, but the problem still exists at least as of this morning's build.

Updated

18 years ago
Status: NEW → ASSIGNED
Summary: [REGRESSION] buttons don't look like buttons → [Dogfood][REGRESSION] buttons don't look like buttons

Comment 2

18 years ago
This is an easy fix.  Each dialog just needs the appropriate line in either the
xul or css (each case is different) that pulls in the global skin file.  I have
fixed some of these in my local tree already because I don't like using the
product in the current state.  Marking as dogfood to see if the PDT group will
bless this one.

Comment 3

18 years ago
XUL windows/dialogs always load their package's master skin file, which is just
the package name, e.g., chrome://messenger/skin/.  XUL files NEVER load the
global skin file.

The master skin files for all packages should already be set up to import the
global skin.

Comment 4

18 years ago
*** Bug 21403 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
Paul, how many other places does this need to be fixed?  Should we file separate
bugs for each dialog?  (BTW, I agree this sucks and it should be PDT+.)

Updated

18 years ago
Whiteboard: [PDT-]

Comment 6

18 years ago
Putting on the PDT- radar. Not mandatory for dogfood.

Updated

18 years ago
Target Milestone: M13

Comment 7

18 years ago
Moving to M13 because of PDT-

Comment 8

18 years ago
Um, excuse me, but this has serious usability implications for all our dialogs.
You can't tell the buttons apart, heck, you can't even tell which are buttons and
which are not. Someone who doesn't know the history of the problem is going to be
completely confused by our dialogs.

I SERIOUSLY think that this should be PDT+

Comment 9

18 years ago
Cc:ing self so I can see this bug bouncing down the path to M15

Comment 10

18 years ago
What is the real fix here? How many files?

Updated

18 years ago
Whiteboard: [PDT-]

Comment 11

18 years ago
The fix for this is incredibly easy, as long as hyatt approves. Hyatt - these
are global dialogs, so there's no component-specific CSS that inherits
global.css.

Here's my fix:

Index: dialogOverlay.xul
===================================================================
RCS file: /cvsroot/mozilla/xpfe/global/resources/content/dialogOverlay.xul,v
retrieving revision 1.5
diff -u -r1.5 dialogOverlay.xul
--- dialogOverlay.xul	1999/09/14 01:50:14	1.5
+++ dialogOverlay.xul	1999/12/10 21:23:02
@@ -1,4 +1,5 @@
 <?xml version="1.0"?>
+<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
 <?xul-overlay href="chrome://global/content/platformDialogOverlay.xul"?>

 <!DOCTYPE window SYSTEM "chrome://global/locale/dialogOverlay.dtd">

Comment 12

18 years ago
removing PDT- -- this bug should really be a PDT+, users will not be able to
distinguish what is a button -- as in things like submit, cancel, yes, no and
what isn't a button. Please reconsider this one folks.

Comment 13

18 years ago
oops, after talking to hangas, that's the wrong file. It should be
commonDialog.xul, but the fix is exactly the same.

Updated

18 years ago
Whiteboard: [PDT+]

Comment 14

18 years ago
PDT was happy to see the small fix... if it grows larger, you'll have trouble
getting checkin approval next week.  Please try to get this in as soon as
sufficiently reviewed... you have jar and chofman's approval

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12

Comment 15

18 years ago
Fix checked in.  Added <?xml-stylesheet href="chrome://global/skin/" type="text/
css"?> to commandDialog.xul.  This is not what Hyatt wanted here but it is a good
fix.  Hyatt and I will have to discuss how we want to handle common dialogs in
the future, we can either go with this approach or add a package to support
common dialogs.  The patch alecf first suggested was not used because it would
have caused duplicate loading of global.css for many dialogs.
(Reporter)

Comment 16

18 years ago
Ahhhhhh (relieved sigh) ... thank you, thank you!

Updated

18 years ago
Status: RESOLVED → REOPENED

Comment 17

18 years ago
I've verified that the fix took for most dialogs but there is at least one other
out there that didn't get the fix.
If this happens in the future, I'll file a new dialog-specific bug, but since this
is the first time, I'm going to reopen this bug simply to highlight the fact that
there are more dialogs out there.

The Unknown File -Type Dialog still exhibits the bug. I beleive this is the offending
file--> chrome://global/content/unknownContent.xul

Comment 18

18 years ago
cc: law for the ucth dialog.

Updated

18 years ago
Summary: [Dogfood][REGRESSION] buttons don't look like buttons → [Dogfood][REGRESSION] Unknown content type dialog buttons don't look like buttons
Whiteboard: [PDT+]

Comment 19

18 years ago
Since this bug has morphed from its original form which was PDT+, I'm going to
change the bug summary to reflect the current problem and remove the PDT+ for
reevaluation.

Updated

18 years ago
Resolution: FIXED → ---
Summary: [Dogfood][REGRESSION] Unknown content type dialog buttons don't look like buttons → [REGRESSION] Unknown content type dialog buttons don't look like buttons
Target Milestone: M12

Updated

18 years ago
Status: REOPENED → ASSIGNED
Target Milestone: M13

Updated

18 years ago
Whiteboard: asap

Comment 20

18 years ago
As Phil pointed out this is now a different bug than it used to be.  This bug is
now concerning unknownContent.xul and downloadProgress.xul.  Both need the same
fix of <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> being
added to these files.  This bug is now marked for M13 and will be addressed then.
Hyatt may decide that these "global" dialogs need their own package, in which
case we will take a different approach to fixing them.

Updated

18 years ago
Target Milestone: M13 → M14

Comment 21

18 years ago
M14 since Paul is out sick

Updated

18 years ago
Keywords: regression
Summary: [REGRESSION] Unknown content type dialog buttons don't look like buttons → Unknown content type dialog buttons don't look like buttons

Comment 22

18 years ago
Bumping to M15.
Target Milestone: M14 → M15

Comment 23

18 years ago
Sending to Ben.
Assignee: hangas → ben
Status: ASSIGNED → NEW
this has probably been fixed. 
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 25

18 years ago
VERIFIED fixed with 2000032910 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.