The 'underline links' pref does not work -- turning it off has no effect on the rendering of pages.

M15 ...

Bulk moving Pref UI bugs to new component Preferences.

Move to M16 for now ...

Reassigning for Don

Putting on NEED INFO radar. Can we get a retest with latest build please.

The checkbox is in the UI, bug does nothing. A workaround is to put a file called user.css in {profile dir}/chrome/, and edit the CSS there for links. Most users won't manage this.

Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.

Pref UI is working and setting browser.underline_anchors properly, it looks like layout is not honoring this pref. over to rickg for layout triage.

Giving us a bug TODAY with a deadline to fix TODAY is not leaving much time for the actual work. I'll triage, but don't expect the fix.

I've spoken with MarcA; the issue isn't hard, but it's not a "one-night" fix. The issues are: 1) seperating link styles into their own stylesheet; 2) Reassigning.

1) move :link rules into seperate stylesheet 2) have ua.css import that stylesheet 3) have the pref code fetch the stylesheet from the styleset and enable/disable it depending on the value of the pref., then issue a style-change reflow if the state changed

Don't we need a more general way that prefs can override CSS-controlled appearance? There are quite a few prefs like this, like page background colors etc, and you'll end up with a gazillion tiny CSS files, if you use this approach. Why not either 1) hack the CSS code to override some styles in html.css by looking at prefs when the file is first read in 2. leverage user.css in the profile folder, maybe writing CSS into this file based on pref settings.

Excellent points, Simon. I didn't realize there were many needs to override CSS-defined properties based on prefs... What is the user.css file all about? I am not familiar with it. The idea of a user-specific pref CSS file makes a lot of sense, and writing / removing style rules there based on prefs sounds like a good idea too. Hacking the CSS code to filter the style rules based on the prefs would be very ugly. we would have to enumerate all rules, find the selectors for links, and remove those rules, and the be prepared to put them back in later if the pref is changed back... blah. By the time we *apply* the rules we don't know if they are from html.css or the author's stylesheet, so we cannot hack it there. I like the user.css idea much better - easier to implement and maintain too, me thinks. Is this feature really that valuable? Don't people rely on style-queues to know what is clickable (of course author style sheets may render links differently, but by default users need *some* hint when the mouse is not over the link, and the underline is the de facto link indicator IMO).

Is this feature valuable? Sure, it's one of the first things that I turn off in a new profile, and, on Mac, there is an OS-level setting (in Internet Config) for underline links, as well as page colors. Link color is enough for me. Also, typographic types will tell you that underline is typographically poor, because it interferes with character descenders.

Oh, and hyatt is responsible for {profile}/chrome/user.css, and putting HTML CSS in there for links works.

It would be nice to keep ua.css so it's editable by the user, who can make further adjustments. (Important for power users, but there could also be pre-designed user stylesheets for users with disabilities.) Would it be easier to have code that writes out CSS, or would it be easier to dynamically modify an existing user (or maybe between UA and user?) stylesheet data structure based on the prefs (which I would think would be rather easy, considering it's possible through the DOM, given such a stylesheet)?

The easiset way to achive this is to add the following rule to user.css when the user chooses to disable underlined links: :link, :visited, :out-of-date, :active { text-decoration: none; } When the user chooses to re-enable underlined links the rule has to be removed, or changed to: :link, :visited, :out-of-date, :active { text-decoration: underline; } In either case the stylesheet has to be re-loaded. I am guessing that the pref code can do this pretty easily (if not, then Style will ahve to provide a way to manipulate specific rules, and that probably won't happen for PR2). I'm changing the component back to Preferences. Please advise if the proposed solution is unacceptable.

This was suppossed to go to Preferences... trying again

over to chris...

Actually, the rule will have to be: :link, :visited, :out-of-date, :link:active, :visited:active, :out-of-date:active { text-decoration: none; } ...so that it only affects :active links (and not anything that is clicked). However, I think the :active underlining in html.css (soon to be htmlstd.css) is superfluous, and may be removed. If it is, then the needed rule will just be: :link, :visited, :out-of-date { text-decoration: none; } I'm assuming we don't want author-requested underlining to be overriden; if we do then the rule should have "!important" inserted between "none" and the semicolon.

Just a random thought; instead of going this route of having prefs write out changes to user.css, can we use (or extend) the 'behavior' CSS attribute, and make use of XBL to have css attributes that are overridable in code?

Move to M19 target milestone.

Putting on [nsbeta2-] radar. Removing [5/16]. Did not make feature train.

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

Also note that Internet Explorer has an option to show the underline ONLY when the mouse is hovering over the link itself. Might want to consider a solution that will allow for this, too.

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

FYI: if you want to mirror the IE link hover option, then add the following to the user.css file described in the prior posts (thanks guys!): a:hover { text-decoration : underline; } Or just change the background color when hovering over a link: a:hover { background-color : #808080; }

:link:hover, :visited:hover is better than a:hover (which matches named anchors). See http://www.people.fas.harvard.edu/~dbaron/css/1999/09/links

nav triage team: nsbeta3-

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

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

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

could we get this in for rtm?

Chris, we need to make this pref work for RTM. Or take it out. Will the simple change to user.css work?

similar style sheet problems to bug 22963? Adding attinasi.

Like bug 22963, this one requires that we insert style rules or subvert the style system to make the pref work. I'd prefer to avoid subverting the style system if we can help it... We can either add entries to the userContent.css file or insert style rules via the CSSOM. The problem with the userContent.css file is that it is loaded only at startup, whereas we can insert and remove rules at will using the CSSOM. Bug 22963 has been RTM+'d, so this bug should probably follow suit and be sent back to me, since I have to fix 22963 and this is essentially the same work.

given marc's input above, am clearing the status so that we could [hopefully] get an rtm+ nomination.

over to attinasi for a look.

OK, back to me I guess. I was really hoping somebody would make a call on how important this is, in relation to other RTM issues. Like I said in my comment of 2000-09-29 17:32, this is related to two other pref bugs that I have so I'll try to tackle them all together. Chris K., do you want to rtm+ this one?

I've got this working now and will be attaching the patches very soon (still testing and getting composer to cooperate). Stand by...

cc brade to test prefs in composer.

cc'ing sujay so that he too can test this in composer.

Ooohh! Finally, the 2000101212 build looks to be fixed!

See wrap-up bug 40340 for patches. I have only checked this in on the trunk - still waiting for permission to apply to branch (for RTM of ns6).

Marking [rtm need info] since there's a fix. Please attach the patch to the bug and get r=/sr= for consideration of approval to land in the RTM branch. When this is done, please change the status whiteboard to rtm+

As I said previously, the patch is attached to roll-up bug 40340. It is crazy to try and extricate the underline-pref change from the other pref changes, that is why I am using bug 40340 as a blanket for all of the pref bugs, and why there is a single patch for the colors, link colors, link underlining and font prefs.

Removing rtm, since this is covered by bug 40340.

Fixed by checkin for bug 40340

yes! vrfy fixed using 2000.10.25.09/08-n6 commercial branch bits on linux, winnt and mac. thx a bunch, marc!

I'm seeing this problem again, starting with the 20001031 Mtrunk builds. Can someone confirm this, or have any ideas about it?

warner, what platforms are you using?

I just checked with my 10-31 Netscape Commercial build and it is working fine for me (WinNT).

I'm using Win95 and Win98. Specifically, I'm using the builds from the build bar on mozillazine.org. When I go back to the 2000103004 build, links are correctly rendered (i.e. not underlined). Using the 2000103104 build, all links are underlined.

Reopening. On the trunk, link are always underlined again, irrespective of the pref setting (seen on Mac)

Accepting: my mistake. I accidentally put the :link and :visited text-decoration:underline rules back into html.css in my last checkin of that file. Removing now, and I'm very sorry.

adding r=peterl

I got an sr=buster too, so I checked in the regression-fix to the trunk. Marking FIXED, and again, I extend my apologies for the regression.

thx, marc! warner, let us know how this works for you...

I'm working on verification of the bug #40340 on the trunk builds, so I'd verify this one as well, if this is OK with you. "Underline links" works fine now. Verified on the trunk with nov_3 builds on MacOS 9, WinNT 4, Linux. Removing vtrunk keyword. Marking as VERIFIED.

Yup, working now in 2000110304 build.

I just installed build 2000101014. Links are always underlined. The underline links checkbox has no effect on this. Mozilla M18 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001010

I just installed build 2000101014. Links are always underlined. The underline links checkbox has no effect on this. Mozilla M18 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001010

Why did you install a build that is two months old? Please get a nightly. Remark: FIXED.

vrfy per olga charapaev 2000-11-03 12:06