274471 - hardcoded colors in the Help Viewer

Status: RESOLVED FIXED

(SeaMonkey :: Help Viewer, defect)

Description

[Matthew Woehlke]

The help viewer is using black text with user-specified background color, making
it difficult to read in some situations. According to the related bugs I managed
to turn up (in particular, bug 149048 and bug 197472), this seems to be a
regression from earlier versions which had user-color text on a white backround.

Comment 1

[Jeff Walden (gone starting June 8)]

I assume you mean the background to the text in help topics, right?  If that's
what you mean, that's a problem I hadn't noticed before, but it's definitely
present from a cursory glance at the CSS.  I'll get around to fixing this
sometime in the next month-ish when I have a little more time than I have now.

Comment 2

[Matthew Woehlke]

Correct. Obviously this needs to be fixed in the distros too, but in the mean
time, can you point me at the correct .css to modify so I can fix my own copy?

It's debatably a step backwards, but since there are other colors being used,
I'd vote for making the background white again... and toss in a:?? colors as
well. Otherwise the blue headers risk becoming invisible as well. </mytwocents>

Thanks.

Comment 3

[Steffen Wilberg]

Attachment: don't hardcode the text color, and take https links into account

- removes color:black from the body. Bug 149048 already removed the background
color. There's no need to specify color (or background-color) for normal text.

- adds a rule for external https links. I just changed our u.m.o links to https
to avoid a redirect.

- removes the unused .makeLeftMargin

Comment 4

[Jeff Walden (gone starting June 8)]

Comment on attachment 168772 [details] [diff] [review]
don't hardcode the text color, and take https links into account

r=[e-mail]

Comment 5

[Steffen Wilberg]

Checking in mozilla/toolkit/themes/pinstripe/help/helpFileLayout.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/help/helpFileLayout.css,v  <-- 
helpFileLayout.css
new revision: 1.5; previous revision: 1.4
done
Checking in mozilla/toolkit/themes/winstripe/help/helpFileLayout.css;
/cvsroot/mozilla/toolkit/themes/winstripe/help/helpFileLayout.css,v  <-- 
helpFileLayout.css
new revision: 1.5; previous revision: 1.4
done

Comment 6

[[e-mail]]

What about the :link:hover colour? Maybe we should change it to
:link:hover { color: -moz-activehyperlinktext; }

Comment 7

[Steffen Wilberg]

Yeah, that works fine, and is almost the same as red (it's #ee0000 instead of
#ff0000): http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresContext.cpp#177

Comment 8

[Steffen Wilberg]

-moz-activehyperlinktext uses the color specified by the browser.active_color
pref. Seamonkey does have UI for that, Firefox does not. That color is normally
used when clicking a link (hold the mouse button to see this) and there's no
style sheet overriding it.

So using -moz-activehyperlinktext is much better than hardcoding red. If that is
still the way we want to style hovered links, that is.

Comment 9

[[e-mail]]

Help currently recognizes visited external links. If we want to continue to
support this then perhaps we should style :visited:hover too.

Comment 10

[Matthew Woehlke]

Meanwhile, can anyone help me out? I unzipped:
   "skin/classic/help/helpFileLayout.css" (to "%chrome%/help/")
from "help.jar" in "%FF-install%/chrome" and changed the line in
"installed-chrome.txt" to:
    "skin,install,url:resource:/chrome/help/skin/classic/help/"

Then I edited said file like such:
    body {
        margin: 2ex;
        font-family: sans-serif;
        font-size: 0.75em;
        max-width: 120ex;
    }

Except this has not fixed the problem. Any thoughts?

(I've restarted FF several times since.)

Comment 11

[Steffen Wilberg]

Matthew, delete chrome.rdf after modifying installed-chrome.txt. A simpler way
is to put the modified file back into help.jar.

Comment 12

[Steffen Wilberg]

Attachment: use -moz-activehyperlinktext for :link:hover and :visited:hover

How about this? See comment 8 about -moz-activehyperlinktext.

Comment 13

[Jeff Walden (gone starting June 8)]

Comment on attachment 169292 [details] [diff] [review]
use -moz-activehyperlinktext for :link:hover and :visited:hover

Makes sense to me.

r=[e-mail]

Comment 14

[Steffen Wilberg]

Checking in mozilla/toolkit/themes/winstripe/help/helpFileLayout.css;
/cvsroot/mozilla/toolkit/themes/winstripe/help/helpFileLayout.css,v  <-- 
helpFileLayout.css
new revision: 1.6; previous revision: 1.5
done
Checking in mozilla/toolkit/themes/pinstripe/help/helpFileLayout.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/help/helpFileLayout.css,v  <-- 
helpFileLayout.css
new revision: 1.6; previous revision: 1.5
done

Comment 15

[Matthew Woehlke]

(In reply to comment #11)
> Matthew, delete chrome.rdf after modifying installed-chrome.txt. A simpler way
> is to put the modified file back into help.jar.

Um... problem. Help is now totally gone; Help menu has 'prompte' and 'about'
only... and there's some sort of error at the bottom of all my FF windows, now.
Visible text is '<key id="key_openHelp" with a carrot pointing to the '<'.

Before, I was getting an error (similarly illegible; window text (white) on
bright yellow background) when I tried to bring up help that said something
about "chrome://content/help/help.xul" having some error in the line '<key
id="key_find"...'.

As best I can tell, everything started breaking when I deleted chrome.rdf. Any
thoughts other than reinstalling?

Comment 16

[Steffen Wilberg]

Targetting bugs which were targetted to Firefox1.1 before the move to
mozilla1.8beta2.