189833 - text-decoration property not reset when switching from alternate stylesheet back to preferred

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[mark bokil]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030119
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030119

In the page http://bokil.com switching to the alternate style sheet and then
back to the preferred style sheet causes anchor tag links with the style
text-decoration: underline to fail to render correctly resulting in underlining
temporarily cutting through the link text instead of adjusting to the baseline
of the text.

Reproducible: Always

Steps to Reproduce:
1. switch to alternate style sheet with larger font-size than preferred sheet
2. switch back to preferred sheet
3. notice text-decoration: underline styling is rendered incorrectly

Actual Results:  
text-decoration:underline style doesn't reflow correctly with document layout
and fails to render at baseline of anchor tag links.

Expected Results:  
text-decoration:underline styles would reflow with document layout and render
correctly at the baseline of anchor tag links.

temporary workaround: force page to reload after switching styles using
javascript: location.href=location.href

Comment 1

[Ruslan Ismailov]

Well, I see this effect. Seems, that underlined line is not redraw. 

Comment 2

[Ruslan Ismailov]

O'k. Source of this behaviour is in setActiveStyleSheet function. When you
switching form Larger to Normal, there is a moment when bowth of styles are
applied. So then when you disabled Normal, underline is not redraw, because this
properety alive.

So better workaraound would be rewrite setActiveStyleSheet:

function setActiveStyleSheet(title) {
  var i, a, main;
  for(i=0; (a = document.getElementsByTagName("link")[i]); i++) {
    if(a.getAttribute("rel").indexOf("style") != -1 && a.getAttribute("title")) {
      a.disabled = true;
    }
  }
  for(i=0; (a = document.getElementsByTagName("link")[i]); i++) {
    if(a.getAttribute("rel").indexOf("style") != -1 && a.getAttribute("title")
      && a.getAttribute("title") == title) a.disabled = false 
  }
}

Comment 3

[Boris Zbarsky [:bzbarsky]]

We should be reflowing correctly no matter what order the stylesheets are
toggled in, Ruslan.

I suspect the problem here is the same as in bug 170644

Comment 4

[Ruslan Ismailov]

Oh, I agree, it's definitly bug (I only want to find a correct workaround here).

Comment 5

[Chris Hester]

Attachment: Normal stylesheet for the bug test

This style is the default one set on the page. Further styles are added 'on
top' as is legitimate according to specifications. I do this by leaving out the
title on the link tag in the head of the document for this stylesheet only.
Thus it always occurs, but an alternate stylesheet chosen can override it.
Saves having to duplicate masses of code - I just add the bits that have
changed (such as colour and font size). See
http://devedge.netscape.com/viewsource/2002/preferred-stylesheets/

Comment 6

[Chris Hester]

This bug occured on our website at work but I finally nailed it this morning
with a testcase:

http://www.brad.ac.uk/admin/neupg/bug.html

There are two pages (important) which use the JavaScript Styleswitcher from A
List Apart to change between two stylesheets. (Although the Mozilla menu will
also change them.) The first stylesheet sets up the positioning and so on, while
the second stylesheet enlarges the font size.

What happens is several things, not just one:

1) When changing from the default ('normal') style to the larger one, the links
are not quite right - the underline is too short. Note also that the focus box
(shown by the dotted lines around the link text) matches the length of the
underline and so is also too short.

2) Text in the link spills out into the surrounding text! Thus it overwrites it.

When changing back to the normal style though, more weird things can happen:

3) Layout can be affected - I've seen divs become too narrow on our work site

4) Sometimes the underline on links can also be too high, looking almost like
the link is striked out, or it just touches the text

5) Gaps have been witnessed where text before a link has a huge space

Now in Mozilla 1.2 you could click on the link for the normal stylesheet twice
and it would right the page. But I notice in 1.4 that this is no longer possible.

As I said though I've nailed the bug, so here's the first thing that causes it:

In the tests you will notice that it depends on the 'position' value given to
each div. When the position is 'absolute' or 'fixed' the bug appears. But when
it is 'relative' or a non-styled element, the bug doesn't show.

Now there are two test pages. They show another strange effect. Do this:

a) Start from Page 1. Ensure page is looking normal and smaller style is
selected (background will be white)
b) Change style to larger (background is now purple)
c) Move to Page 2 in the test!
d) Now change style back to normal.

You will notice that there is a gap after each link where the underline carries
on. Note also the gap before the link in the div set with 'position:fixed'. Now
we see the opposite problem in that enlarging the text makes the links normal.

There's also a strange effect where the lines move down a little on Page 2 if
you've set Page 1 to larger first. (Or the other way round.) Not sure why. 

Now there's a final reason for the bug: I found that it only happens when a
font-size is set on the body in an alternate stylesheet. If you set elements
like p or div instead you are safe.

I'll attach the stylesheets so you can see what's what.

Comment 7

[Chris Hester]

Oops, sorry everyone, I posted the stylesheet and comment first. Can someone
remove comment #5?

Comment 8

[Chris Hester]

Attachment: Larger (alternate) stylesheet

Larger (alternate) stylesheet

Comment 9

[Chris Hester]

Form elements are also buggy when switching styles. If you set the *height* of a
select & option form (drop down menu) then the style is only applied to the
options. The top line with the menu arrow next to it remains unaffected. If you
then Refresh the browser, the style is applied correctly.

But then the style 'sticks' so other styles chosen have the same height, even
when they declared a different one. You have to refresh again to restore the
correct height.

This occurs whether the initial style LINK tag has a title given to it or not.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

comment 9 is not related to this bug.  Please don't add unrelated comments to bugs.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The site doesn't resolve, and I don't see a testcase.  If someone can produce a
testcase, that would be nice -- I think I have a patch that should fix it...

Comment 12

[Chris Hester]

Attachment: Testcase HTML CSS & JavaScript files

Testcase.

Comment 13

[Boris Zbarsky [:bzbarsky]]

So what are the steps to reproduce and the expected behavior with that testcase?

Comment 14

[Chris Hester]

1. Extract all files to the same directory and open bug.html

2. Click the link marked "Click here for Larger text". (The screen changes to
lilac.) Note the link text overlaps the text following it on "Normal view" and
the "position:fixed" line, second from bottom.

3. Click on "Link to Page 2" and notice the link text recedes (is displayed
correctly).

4. Now click on "Normal View" and notice the spaces before links, along with the
extended underlined spaces after them.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I see that, and that's a bug (and I think we have other reports of it), but what
does that have to do with _this_ bug (which is about text-decoration not
following the text)?

Comment 16

[Chris Hester]

I guess I am in the wrong bug page. Maybe the bugs are related though? Both
include a faulty redraw triggered by alternate stylesheets and link text. I am
sorry for any confusion caused.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Yeah.. I think you're seeing bug 241626.

Comment 18

[Boris Zbarsky [:bzbarsky]]

The site in the URL field is not resolving, and there are no testcases for the
originally reported bug, so marking worksforme.  Please reopen if there is still
a problem....