Closed Bug 280772 Opened 20 years ago Closed 20 years ago

Strange Thin Lines Appear to the Left of Links with CSS Hover Attributes

Categories

(Firefox :: General, defect)

PowerPC
macOS
defect
Not set
trivial

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: firefox_report, Assigned: bugzilla)

References

()

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I can't for the life of me figure out exactly what is causing this but this is
definitely a bug in Firefox. I am not alone. Look at this thread on
Webmasterworld: http://www.webmasterworld.com/forum83/4995.htm

Reproducible: Always

Steps to Reproduce:
1. Open the Web Site
2. Roll Over a Link
3. There is no Step 3. Tee-Hee!

Actual Results:  
Thin lines of background color appear to the left of the links, and also of
images that were rolled over during the hover (via an onmouseover().)

Expected Results:  
Not shown the lines.

You have GOT to be kidding! I spent the better part of half an hour searching
through the bug DB and Google for solutions to this problem. When I tried to get
more specific (so I don't get sixty gazillion returns for the word "lines,")
Bugzilla hangs. You guys are nuts if you think that people will spend that much
time trying to find out if a bug has already been reported.
I would not be at all suprised if the bug has already been reported, but, if you
read the thread I reference, you'll see that at least one webmaster didn't
report it because of the Bugzilla stumbling blocks.
I want to code my pages to fix this. I am actually not at all interested in
making Firefox fix this, as millions of copies of the errant version are out
there already.
A very big help would be a way to publish workarounds.
no such thing here with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201
or
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050127 Firefox/1.0+

maybe Mac OS only?
Yup. I'm almost sure of it.

I'm using OS X 10.3.7 on a PBG4/1.5GHz/1MB/80GB.

It does not happen on every single page (for instance, it doesn't happen on this
one: http://www.cmarshall.net/links/index.php), which is very strange. I can't,
for the life of me, figure out what makes the difference. The site is based upon
Dreamweaver templates, so the vector is in the content.
i've ordered myself a new powerbook g4 :D but until then someone else has to see
if this can be reproduced.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050203
Firefox/1.0+

Mac OS X 10.12.6

WFM (not seeing the glitch)

See 
Bug 279486 "links leave trails when hovered and then unhovered"
Bug 96041 "leftmost pixels of overflowing 'j' / 'W' don't get hover color (text
frames should set overflow area)"
I can't NOT make it happen. It happens no matter what I try.
However, I think I know of a major common factor. This happens in a couple of my
sites, but not others. It does not seem to be based upon the HTML/XHTML version.
It also happens on an HTML 4.01 Transitional site I run.

The common factor seems to be a variant of
.style_decl{background-repeat:repeat;background-image:
url(../images/backgrounds/backGtexture.gif);background-attachment: fixed;}.

It only happens in table layout cells with a background image displayed over
another background image. It is not enough for it to just be a background image;
it must be displayed on top of another background image.

I would LOVE to know of a workaround I can code into my pages. It is quite annoying.
(In reply to comment #6)
Hang on
> I can't NOT make it happen. ...
> 
> The common factor seems to be a variant of
> .style_decl{background-repeat:repeat;background-image:
> url(../images/backgrounds/backGtexture.gif);background-attachment: fixed;}.
> 
> ...

If you have a common factor, are you able to produce a minimal 
test-case: The shortest file that has the problem. I am sure that
everyone believes that the problem is real, it is just that few
people are known to have seen it.

BTW, my lizard is todays build from the trunk. Yours is a release version.
Whilst it is not an absolute requirement, you might find it helpful
for yourself to check for the problem in a nightly.
Ask, and ye shall receive.
NOTE: If you change the table styles to make the <td> cells 50%, instead of 80
pixels, the problem goes away.
I wanted to give you a screenshot, as it is hard to reproduce on other
machines.
Oops. It doesn't make any difference, but the table styles should look like this:

table.demo_table{
	width: 160px;
	background-image:  url(images/backGtexture_dark.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_background{
	text-align: center;
	width: 80px;
	background-image:  url(images/backGtexture_darker.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_no_background{
	text-align: center;
	width: 80px;
	background-image:  none;
}

If you change it to this:

table.demo_table{
	width: 80%;
	background-image:  url(images/backGtexture_dark.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_background{
	text-align: center;
	width: 50%;
	background-image:  url(images/backGtexture_darker.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_no_background{
	text-align: center;
	width: 50%;
	background-image:  none;
}

The problem goes away.
Just a followup. It seems to be connected with declaring the <table> width as an
absolute pixel value. As I am still a "table layout weenie," this pretty much
spikes many of my Web sites.

If you do this, the problem resurfaces:

table.demo_table{
	width: 200px;
	background-image:  url(images/backGtexture_dark.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_background{
	text-align: center;
	width: 50%;
	background-image:  url(images/backGtexture_darker.gif);
	background-repeat: repeat;
	background-attachment: fixed;
}
td.has_no_background{
	text-align: center;
	width: 50%;
	background-image:  none;
}
Just FYI: These people have the same problem: http://www.scriptsbank.com/
Roll over the top menu.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050204
Firefox/1.0+

(Today's build - standard methods, with this .mozconfig

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=/Users/bfowler/build/The_birds

ac_add_options --enable-extensions=default,-venkman

#ac_add_options --enable-application=browser
mk_add_options MOZ_CO_PROJECT=browser,mail

#mk_add_options MOZ_CO_LOCALES=en-GB
#ac_add_options --enable-ui-locale=en-GB

#for svg
ac_add_options --enable-default-toolkit=mac
ac_add_options --disable-tests
ac_add_options --enable-crypto
#ac_add_options --enable-calendar
ac_add_options --without-system-nspr
ac_add_options --without-system-zlib
ac_add_options --without-system-jpeg
ac_add_options --without-system-png
ac_add_options --without-system-mng
ac_add_options --enable-svg
ac_add_options --enable-svg-renderer-libart

mk_add_options MOZ_CO_MODULE=mozilla/other-licenses/libart_lgpl
)

(In reply to comment #8)
> Created an attachment (id=173261) [edit]
> This is a Minimal Test Case (Mini Site)

The testcase WFM (no abnormal lines), however the rollover
effect on the image only occured the first time I moused over
the left link.
I'll get around to testing with a nightly build.

Just FYI: This only happens in Firefox; not Mozilla, Netscape or Camino (I have
the latest stable release of each.)

However, I am not really interested in whether or not you fix it. A workaround
for my site coding is more along the lines of what I need. In fact, I would
venture to say that most Web designers would feel the same way. We've gotten
used to patching for Internet Exploder and Netscrape quirks.
You would probably ingratiate yourselves to the Web Design world by researching
and publishing workarounds. It wouldn't be embarrassing, as you already have
your internal bug tracking system wide open.
Well, you ever tried to clean a window, and you smeared things aroun, so the
original spot was OK, but all around was kind of a mess?

The latest nightly build works on the test case, and on the original reported
page, but now it fails on a page that used to be OK:

http://www.cmarshall.net/links/index.php

I smell a rounding error.
(In reply to comment #14)
> ...
> However, I am not really interested in whether or not you fix it. 

The community is generally tolerant of contrarian opinions,
videlicet:

    One difference I've noticed between great hackers and smart people 
    in general is that hackers are more politically incorrect. To the 
    extent there is a secret handshake among good hackers, it's when 
    they know one another well enough to express opinions that would 
    get them stoned to death by the general public.

Please be aware, though, that Bugzilla is ONLY for people who are trying to
identify and fix defects in Bugzilla.

If a work around for Chris M. is the only thing on your agenda, then
you will get quicker and better attention from Mozillazine or the CSS
community (and the 'right' to call Bugzilla mean, unfriendly, self-righteous
et cetera).
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050205
Firefox/1.0+

Today's build using standard methods.

I can't see the problem using any of your cases.

On the Rounding Error question, I can see the defect reported in 
Bug 125560 "Rounding error positioning float: right inside block with percentage
margins"
and
Bug 175746 "1px blank line inserted after a series of divs"
and
Bug 173051 "Wrong space between block level elements that have no margin"


You night want to review Bug 63336 "Pixel roundoff problems [gfx]"
Attached image Screenshot 20050104
This attachment is how it looks for me using
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050204
Firefox/1.0+

Can anyone reproduce this bug using a trunk Firefox build from 2005-02-05 or
later?
wfm.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.8b) Gecko/20050123
Firefox/1.0+
Camino 2005020519 (v0.8+)
Resolving as works for me as it can no longer be reproduced in recent builds.

Reporter, if you still have this problem with a trunk build from today or later,
 reopen this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: