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

RESOLVED FIXED

Status

()

P1
normal
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: bartolomesintes, Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
-> 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?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

15 years ago
> 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.
(Reporter)

Comment 3

15 years ago
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)
(Reporter)

Updated

15 years ago
Status: RESOLVED → UNCONFIRMED
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.

Comment 5

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

Comment 6

15 years ago
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.

Comment 8

15 years ago
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
(Reporter)

Comment 10

15 years ago
> 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

15 years ago
@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)
Anne: yeah, that seems to be what the spec says
(Reporter)

Comment 13

15 years ago
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.
Priority: -- → P2

Comment 14

15 years ago
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

15 years ago
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

15 years ago
Created attachment 140865 [details]
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

15 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted → regression, testcase
Created attachment 140867 [details]
Andrew's testcase without "test.html"
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
Created attachment 141579 [details] [diff] [review]
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.
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+
Priority: P2 → P1
checked in
Status: NEW → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.