303840 - overflow: auto or hidden calculates wrong content width

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Navid Zamani]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

here i have a practical testcase:

if you look at the page you see 4 variations of test cases. each are very
similar. they have a dov with contain a div (id=test) that automatically
calulates its width (100%) and a second one that only differs by a
"margin-right: -1".
the 4 cases differ by 2 of them having "overflow: auto" and the other 2 having
"overflow: hidden", and for every variant there is one with and one without
image, resulting in 4 variants.

------------------------

now you can see that the first one (overflow: hidden with image) renders the
width wrong by adding an addional 17px margin at the right of the divs.

the second one (overflow: auto with image) looks good, but when you click on 
his "set second div to display:none", his first div also becomes this 17px narrower.

the third one (overflow: hidden without image) shows, that without the image,
even overflow: hidden has the same bug.

the fourth one (unnamed) is the strangest of the bunch: it gets two variations
of the same bug. first, when you show it with "set stuff below to to
display:block", you see that all correct renderings suddenly become buggy.
except itself! but if you want to get it buggy too simply click its "set second
div to display:none" ;-P

------------------------

i'm now sitting on this for two days and i simply give up because i normally
would read gecko's rendering-code to be able to understand this because i
strongly expect a bug there. but: i still can't read C/C++ :(

some additional information:

it seems that a margin of <0 does work arond the bug. so if you want it to have
a negative margin you can take it as a workaround. but for everything else
(margin >0) with an hidden or scrollable overflow you get this strange behaviour.

i calculated the widths at least 10 times, because i thought i missed something
there. but if i (hopefully) did something wrong... here's my calculation:
body width = 512px
.content width = body width - border-left - border-right - padding-left -
padding-right
              = 512 - 1 - 1 - 8 - 9 = 493px
(no margins or other borders/paddings for all elements inside body. no
padding/border for body)

i guess this thing is pretty hard to crack. but nonetheless it's a very annoying
bug because it makes it impossible to build my site correctly.

Reproducible: Always

Steps to Reproduce:
1. open test case
2. click on "overflow: auto with image" > set second div to display:none
3. click on "set stuff below to to display:block"

Actual Results:  
see above

Expected Results:  
the first div (.test) should have a distance of 9px to the right (red) border of
its surrounding .content and not 9px + 17px = 26px.

see above

Comment 1

[zug_treno]

Related to Core bug 286814 -> Core bug 284242?

Comment 2

[Navid Zamani]

oops... if core means gecko then this certanly should go to core. i did not see
that it existed when i entered the bug report.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The testcase seems to be 404...  If there's a page showing this problem, please attach it to this bug and reopen the bug, ok?

Comment 4

[Navid Zamani]

Attachment: Testcase A

Well... this bug is so old that i forgot the file was related to any bug...

Now it's (mostly) attached. (The testcase does not work without the image, but i was too lazy to do an inline-encode of it. ;] The new location will stay pretty long there.)

Comment 5

[Boris Zbarsky [:bzbarsky]]

So what is the problem?  I don't see any 17px width changes with that testcase.  Do you, with a Firefox 1.5RC3 or current trunk build?

Comment 6

[Navid Zamani]

(In reply to comment #5)
>  Do you, with a Firefox 1.5RC3 or current trunk build?

Look at comment #1 ;)

I'm right now using 1.0.7 and the bug's still there.

You can't simply look at it to see the bug. You have to follow the steps to reproduce it. You also have to let the page load fully *without* letting the mouse go over any area of it! (or better, to be sure disable all extensions temporarily)

I now have installed the TargetAlert extension and it happens when i just hover over the second or third "set second div to display:none" link (because a small target alert symbol pops up). Pay attention to the right border of the blue divs directly above the link.

When you don't have such an extension installed, then i will happen when you acually click on those links. (the blue divs directly above are becoming smaller for no reason.)

Remember that this does *not* happen on the *first* "set second div to display:none" link! This one is just there for a comparision!

If it really does not happen on 1.5, then we can close the bug and smile. ;)
But please try to really state what you did to reproduce it so we can be sure you nut just loaded the page, saw nothind and closed the bug. ;))

Damn i HAVE to learn C++ so i can look at this stuff myself! (Instead of playing with Haskell... ;)

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I'm right now using 1.0.7

That's code from April 2004, with only security fixes since then.  Again, please try 1.5RC3 or a current trunk (1.6 alpha) build, NOT one of the 1.0.x builds.

> You have to follow the steps to reproduce it.

I did.  Perhaps I'm not following what the problem is?  Is the problem perhaps that a vertical scrollbar appears where there didn't use to be one?  Comment 0 is not very clear on how to actually tell apart the expected and actual rendering.

Comment 8

[Navid Zamani]

Attachment: Testcase A - Fully automated ;)

(In reply to comment #7)
> Again, please try 1.5RC3 or a current trunk (1.6 alpha) build, NOT one of the 1.0.x builds.

Well... i just tried... and guess what... i can't try... 'im sorry. If you want, then kill this bug, because i can't install 1.5x anytime soon... (because it would take weeks to restore the system to a workable state... for *this* system...)

If i find a friend with a 1.5 on his system i'll take a look and put a new bug in it if it's still there...

> I did.  Perhaps I'm not following what the problem is?  Is the problem perhaps
> that a vertical scrollbar appears where there didn't use to be one?

No. The problem even looks similar to something i saw in the IE (*shudder*) very often. It's caused by the browser calculating the size of an element while the page is still not fully loaded or loading...i guess. I don't know why it's calculated apparently too early, but i know that when you force the browser to re-render the area it just says *whoops* and draws it correctly (or wrongly, if coded that way).

I did two screenshots and took a "diff" of them to show you exactly where i see the problem.
This example is attached as "Testcase A - Fully automated ;)".
Just look. If this does not happen on the not automated testcase for you when you do exactly these steps
1. load page and move mouse at right side of screen
2. move mouse on marked link while not forcing any re-render and click on it
then you can surely close this bug.

Hope that finally clears it. :)

And btw: Keep up the good work!
(I know sometimes in all these rants you're missing some motivation when you're a debugger. Okay... counts for most other situations too these days... ;)

Comment 9

[Navid Zamani]

Comment on attachment 204099 [details]
Testcase A - Fully automated ;)

uhum... if your browser automatically tries to fit the image into the frame... please resize it to back normal size and scroll down to the "click here"/"look here" markers.
"thank you, and enjoy the show" ;)

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I did two screenshots and took a "diff" of them to show you exactly where i see
> the problem.

Yeah, I don't see that with a current Gecko....

Comment 11

[Navid Zamani]

Well then it mist be fixed. :)

Thank you for helping me that much...

Comment 12

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME