Closed Bug 232951 Opened 21 years ago Closed 21 years ago

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


(Core :: Web Painting, defect, P1)






(Reporter: bartolome.sintes, Assigned: roc)




(Keywords: regression, testcase)


(2 files, 1 obsolete file)

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
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:

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.

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

It is rather strange that it did work in 1.6b, are your certain you didn't
change anything?
Closed: 21 years ago
Resolution: --- → INVALID
> 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:
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.
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)
Resolution: INVALID → ---
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.
Note that neither of the 2 test cases he applied has the correct content-type.
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?
> 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.
Resizing the browser to cause a reflow fixes the layout on the URL.
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?
Assignee: dbaron → roc
Component: Style System (CSS) → Layout: View Rendering
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
> 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).

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)
Anne: yeah, that seems to be what the spec says
I have prepared two testcases: is the good one. 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.
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... 
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.      
Attached file testcase (obsolete) —
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.
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

bug still occurs with linux trunk 2004020708
Ever confirmed: true
Attachment #140865 - Attachment is obsolete: true
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....
Depends on: 227458
Attached patch fixSplinter Review
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.
Attachment #141579 - Flags: superreview?(dbaron)
Attachment #141579 - Flags: review?(dbaron)
Attachment #141579 - Flags: superreview?(dbaron)
Attachment #141579 - Flags: superreview+
Attachment #141579 - Flags: review?(dbaron)
Attachment #141579 - Flags: review+
checked in
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.