lines become visible , when the opac div is set to hidden




Layout: View Rendering
14 years ago
8 years ago


(Reporter: Peter Grabner, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)




(7 attachments, 2 obsolete attachments)



14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

if you set opacity style to a div-container,
an give this div "hidden"-style.

in effect i mean like this:
style="-moz-opacity: 0.5; visibility:hidden;"

lines become visible , when the opac div is set to hidden.
(the lines are visible at the border of the hidden div.)

the visibility of the lines or fragments depends on size of the browser window,
- more often seen if window is smaller.
(come and go - if you resize the window some pixel)

if they are visible a reload does not change anything.

it doesnt make a difference if you look with firefox (-moz-opacity), or the new
 w3c opacity-style (opacity:0.5;) implemented in the new mozilla 1.7b.

this problem came with one of the latest versions (before firefox 0.8 and a
newer version of mozilla like 1.6)

problem was seen on different hardware.

Reproducible: Always
Steps to Reproduce:
1. load:
2. move over the round images, to see where the unvisible div's are (javascript
3. if there are no lines, resize the window (to smaller size).
(could see the problem on any div, - but prevent to use opacity)
I don't think this has anything to do with Bugzilla....
Assignee: justdave → general
Component: Bugzilla-General → Browser-General
Product: Bugzilla → Browser
QA Contact: mattyt-bugzilla → general
Version: unspecified → Trunk
Minimal testcase and preferably exact instructions that make this 100%
reproducible would be nice.... (like which exact size the window should be sized
Assignee: general → roc
Component: Browser-General → Layout: View Rendering
QA Contact: general → ian

Comment 3

14 years ago
Created attachment 146581 [details]
first file of testcase

Comment 4

14 years ago
Created attachment 146582 [details]
second file of testcase


14 years ago
Attachment #146581 - Attachment is obsolete: true


14 years ago
Attachment #146582 - Attachment is obsolete: true

Comment 5

14 years ago

1. load:

(it is possible that you see dark-blue lines - at right bottom..)

2. do a mouseover on the round images, with javascript enabled..
to see the "message-boxes" visible..

3. move the mouse out.

4. if you dont see that dark-blue lines..
please take the window at the right bottom,
to resize permanently (size to a very little window, too)

- the dark lines will be visible,
where the hidden divs had their borders,
if they where visible..

- the reload after every resize can you disable then via "javascript disabled"
(after you have seen where are the refering hidden boxes)
-> Javascript doesnt matter to the problem now..

there is no exact size of the window to tell,
thats an additional sign that points to a browsers problem

.. think its not unimportant that i have not watched on this,
with another os than win2000 (nt4),
- but it where very different hardware

.. have seen the problem on other hidden div with opacity,
and didnt use opacity for that reason

.. is that there are no lines,
- when the div has no opacity

i will make a testcase, that reflects this problem 
- IF YOU CAN CONFIRM that strange lines..
(because i expect, it could be harder to find the causing components)

Comment 6

14 years ago
see an additional line, of that document if (for test) doc switched to:
strict standard mode
(under the hiden li-menu -> button international)
Yeah, looks like this is Windows-specific (I tried the NS_PAINT_SEPARATELY
ifdef, and I still can't reproduce on Linux).

Though I wasn't very clear on what exactly I was looking for; a screenshot would
have helped a lot....

Comment 8

14 years ago
here is the testcase:

(could get a testcase, where a line is ever seen,
but that would be much more code)

between you asked for a screenshot,
..will be attached
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 9

14 years ago
Created attachment 146598 [details]

Comment 10

14 years ago
the screenshot-format (jpg) has blurred the line..
.. on my windows
the line where ever exactly 1 pixel in height

Comment 11

14 years ago
Created attachment 146600 [details]

such a line seen under something other conditions..
.. cant see, a direct dependency to an opac element
- so far i look at its direction and position.

Comment 12

14 years ago
Created attachment 146601 [details]
background of "another line" (as described)

oh there was a background..
..the hidden div "shopping-basket".

but dont know or find any opacity on it .. least opacity is a factor for that strange lines

Comment 13

14 years ago
Created attachment 146608 [details]
testcase absolute reduced

testcase absolute reduced

if you remove any of that style-components,
.. problem will be not there



filter:alpha(opacity=92); -moz-opacity: 0.8; opacity: 0.8;

Comment 14

14 years ago
Created attachment 146617 [details]
correction of testcase

the font is not "crucially"

the two parts that really produce this problem are


line-height moves the "origin" of the problem..
so that the "strange-lines" become visible - on other positions/window-sizes.

Comment 15

14 years ago
How was this "fixed"?  All I can see are test cases.  Was something checked in
somewhere?  If it's simply working now it should be WORKSFORME; if nothing was
changed in Mozilla, and a workaround (or correct approach to coding) found then
it should be INVALID since it was never a bug...


14 years ago
Resolution: FIXED → ---
I don't understand what's going on here. Could we have a screenshot of the last
reduced testcase?
Priority: -- → P2

Comment 17

14 years ago
Created attachment 146915 [details]
line becomes visible at a window-size of 786x591

.. line should NOT be there, - this strange line is the bug

Comment 18

14 years ago
Created attachment 146916 [details]
NO line at a window-size of 784x590

.. and that strange löine is not visible at 784x590 window-size

(both screenshots under win2000)
OK, I see. Looks like it could be a Windows toolkit bug. Summoning help.

Comment 20

14 years ago
After only a quick look I would give my vote to a rounding error somewhere.


14 years ago
Ever confirmed: true

Comment 21

13 years ago
(In reply to comment #19)
After a while have seen that the problem looks the same under linux.
Such lines in x- and y-direction (fragments) are visible under some conditions.

(It seems even when there is no opacity. - In the sample of my earlier testcase
- opacity has played a role.)
You can see another sample if you go to:

- and change the with of the window to 853 pixel (a sample).
Even the gif-image is broken - when you look at the "n" in the image, - there is
a 1 pixel offset whithin the image.
(You should try some other widths).

I agree that it looks like a rounding error - or maybee a timing or "to early
stopped" error.
** It remembers me to what I have seen, after scripting some dragable elements.

Wile moving some elements with the mouse the movement looks a little bit like
"ander floating water". - In other words the fragments of the element dont move
in the same step-size.
Even some *surrounding* Elements / images are visually changed til i stop
dragging the element.
- Could say - a little bit like moving an eyeglass or magnet above these
surrounding elements.
(As an Effect of particially redraw - it must be a trickie made code.)

To me it looks like sometimes that algorithm / work is stopped before it is all
ready done / refreshed.
So there are some fragements left - also when resizing the window.

Comment 22

12 years ago
now these lines are not seen anymore. - last testcase - through ff and W2k. - the refreshing looks different.

i think this should be another problem, but have often seen similar lines - ALSO depending of the window size.
the lines are exactly at the right border of a hidden div. - along the left side of the Y-scrollbar (inner side - where it scrollbar would be - when switched to visible).
that may be similar lines - but it should be a different bug. - if helpful anywhere, i have screenshots and could build a testcase ..
QA Contact: ian → layout.view-rendering

Comment 23

9 years ago
Actual (after a few years) - I watched this again - using the same system as before (w2k) - but with ff-3.5.2 of course.
It looks like the rendering-problems - which I have reported - must be solved in the meantime. - I tried the same testcases, but all the resizing, which I also did before, is turning out in a perfect rendering.
(If it's OK with linux too ? - I can't tell these days.)
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.