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).
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.
Status: NEW → ASSIGNED
Summary: [REGRESSION] buttons don't look like buttons → [Dogfood][REGRESSION] buttons don't look like buttons
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.
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.
*** Bug 21403 has been marked as a duplicate of this bug. ***
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+.)
Putting on the PDT- radar. Not mandatory for dogfood.
Moving to M13 because of PDT-
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+
Cc:ing self so I can see this bug bouncing down the path to M15
What is the real fix here? How many files?
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">
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.
oops, after talking to hangas, that's the wrong file. It should be commonDialog.xul, but the fix is exactly the same.
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
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12
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.
Ahhhhhh (relieved sigh) ... thank you, thank you!
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
cc: law for the ucth dialog.
Summary: [Dogfood][REGRESSION] buttons don't look like buttons → [Dogfood][REGRESSION] Unknown content type dialog buttons don't look like buttons
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.
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
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.
M14 since Paul is out sick
Summary: [REGRESSION] Unknown content type dialog buttons don't look like buttons → Unknown content type dialog buttons don't look like buttons
Bumping to M15.
Target Milestone: M14 → M15
Sending to Ben.
Assignee: hangas → ben
Status: ASSIGNED → NEW
this has probably been fixed.
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
VERIFIED fixed with 2000032910 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.