232951 - A page that worked in 1.6b but does not work in 1.6: divs inside a div

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P1)

Description

[Bartolome Sintes]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

The following page does not work in Mozilla 1.6 but it did in Mozilla 1.6b: <a
href="http://www.mclibre.org/consultar/amaya/ejercicios/emperadores/Emperadores_Romanos_Formateado.html">Roman
emperors</a>
When you click the right or left coins, the center of the page should show
different roman emperor short biographies (in Spanish).
The structure of the page is quite simple: every emperor biography is contained
in a div ( position: relative; overflow: auto; width: 100%; height: 100%; } and
all these divs are in a big div { position: absolute; overflow: hidden; top:
10%; left: 20%; width: 60%; height: 80%; }.
W3C HTML and CSS validators give no errors in this page.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




This page is shown OK in Internet Explorer.
I am the author of the page, so I can make easily any change it is needed.

Comment 1

[Anne (:annevk)]

-> INVALID

Wrong content-type, should be 'text/xml', 'application/xhtml+xml' or
'application/xml'.

It is rather strange that it did work in 1.6b, are your certain you didn't
change anything?

Comment 2

[Bartolome Sintes]

> Wrong content-type, should be 'text/xml', 'application/xhtml+xml' or
> 'application/xml'.
Why? In any case, I have created two pages with the first two content types you
are suggesting:
http://www.mclibre.org/consultar/amaya/ejercicios/emperadores/Emperadores_Romanos_Formateado_xml.html
http://www.mclibre.org/consultar/amaya/ejercicios/emperadores/Emperadores_Romanos_Formateado_application.html
and they do not work.

> It is rather strange that it did work in 1.6b, are your certain you didn't
> change anything?
I have uninstalled Mozilla 1.6. I have installed Mozilla 1.5a and the page is
shown OK. I have then installed Mozilla 1.5b and the page is still shown OK. I
have the installed Mozilla 1.6 and the page is badly displayed.

Comment 3

[Bartolome Sintes]

Sorry, I meant I have installed Mozilla 1.6a and Mozilla 1.6b (I think Mozilla
1.5a and 1.5b did not displayed this page properly, but I am not sure, I can
test it if it is needed)

Comment 4

[Hixie (not reading bugmail)]

This does seem valid; we're not scrolling overflow:hidden elements to reach 
parts of a document that are hidden due to that.

Need a testcase to confirm though.

Comment 5

[Anne (:annevk)]

Note that neither of the 2 test cases he applied has the correct content-type.

Comment 6

[Anne (:annevk)]

Just as I expected.

Mozilla supports map[name=map]:not([id=map]) in 'text/html' and map[id=map] with
a XML based content-type.

Is that correct Ian?

Comment 7

[Hixie (not reading bugmail)]

> Mozilla supports map[name=map]:not([id=map]) in 'text/html' and map[id=map] 
> with a XML based content-type.

I'm not sure what this means (what has CSS got to do with this? Please don't use
timeless' style of trying to be "terse", just write real English so we can be
sure we understand what you mean) but either way, what does the spec say? (I
think it says what you meant.)

Anyway the page has been changed now, and it shows even more bugs. We need
(preferably guideline compliant) testcases for each individual problem.

Comment 8

[José Jeria]

Resizing the browser to cause a reflow fixes the layout on the URL.

Comment 9

[Boris Zbarsky [:bzbarsky]]

This is not looking like a style system issue.  It's looking more like a
painting/scrolling problem -- after I click a link the new stuff is not painted
in the right spot and if I lower and then raise the window I get a nice gray
rectangle there... In addition, DOM inspector is confused about where frame
bounds lie (though that could be an inspector bug).

A testcase (a page as small as possible, with as little style as possible, that
still shows the problem) would be nice here....  Bartolome, do you have time to
reduce the page to the minimum that's still buggy, by any chance?

Comment 10

[Bartolome Sintes]

> Bartolome, do you have time to reduce the page 
> to the minimum that's still buggy, by any chance?
Yes, I will do it today (let's say within 12 hours).

Comment 11

[Anne (:annevk)]

@Ian

A simple example (when I find time, I'll create a test case):

<img usemap="#map"/>
<map id="map"/>

This does work with an X(HT)ML content-type, like 'text/xml' or
'application/xhtml+xml'. This doesn't work with the HTML content-type, 'text/html'.

With the HTML content-type the only possible way is to use a NAME attribute:

<map name="map"/>

(Of course, you can add the ID attribute as well for other browser that do
support it)

Comment 12

[Hixie (not reading bugmail)]

Anne: yeah, that seems to be what the spec says

Comment 13

[Bartolome Sintes]

I have prepared two testcases:
http://www.mclibre.org/mozillabug_232951/test_232951_good.html is the good one.
http://www.mclibre.org/mozillabug_232951/test_232951_bad.html is the bad one.
The first one is shown OK in Mozilla 1.6. The second one is badly shown in
Mozilla 1.6. The difference between them is just an "overflow: auto" in the
inner div. If it is not present the page is shown OK, but if it is present the
page is badly displayed.
In IE or Mozilla 1.6b both pages are shown OK.
I have added an id="name" to the <map>, because W3C validator wants it (it does
not affect Mozilla behaviour)
I hope it will help you.

Comment 14

[Magnus Melin [:mkmelin]]

Don't know if it's relevant but also in comment 0 if you click on the url and
click on some coin pic, and then swich to another tab, when you come back it's
just a grey area where the text sould go... 

Comment 15

[thinkerdreamer]

I've noticed this bug in a web site I created and took down. The reporter has it
right.  Mozilla doesn't properly support Div's in Div's. Sorry, but I can't give
you the URL.  My web site was perfectly coded W3C approved. I could put their
button on my page. I hope this helps. Sure would be nice if this was fixed.      

Comment 16

[Andrew Schultz]

Attachment: testcase

with linux trunk 2004020708, the testcase displays ok on initial load.
click "Second" to show the "Second" DIV below the first one (it should appear
where the first one is)

for more fun, move a window over the Mozilla and then re-expose the Mozilla
window.  The "First" link then appears in the middle of the page and part of
the top DIV is dark grey.

Comment 17

[Andrew Schultz]

this regressed between linux 1.6b (2003121012) and trunk 2003121209, but nothing
in that window looks relevant.

bug 227458 made it in the night before 1.6b, but conceivably did not make it in
1.6b.

bug still occurs with linux trunk 2004020708

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Andrew's testcase without "test.html"

Comment 19

[Boris Zbarsky [:bzbarsky]]

Testing with nightlys, the regression happens between "2003-12-09-16" and
"2003-12-10-09", so this does in fact look like bug 227458....

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

The bug was that nsScrollPortView::Scroll forgot to move child widgets when
scrolling without a widget. This is an old bug exposed by the overflow:hidden
changes and subsequent optimization to have overflow:hidden not use a widget.
One probably could have triggered it before by somehow making a listbox contain
content with a widget.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in