Closed Bug 34031 Opened 24 years ago Closed 21 years ago

overflow:scroll causes abs. pos. element's positioning to NOT be relative to the parent

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: savov, Assigned: eric)

Details

(Keywords: testcase)

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (WinNT; I) this is my mail-client
BuildID:    2000032718 
i am talking about Mozilla M14

events doesn't fire when they are put through createContextualFragment
if handly put event handlers through setAttribute everything is ok
another one is about CSS position attribute
i think it must refer to parents element position

Reproducible: Always
just look at the source:
<html>
<title>haven't got :events & position:absolute in innerHTML</title>
<script>
HTMLElement.prototype.innerHTML setter = function (str) {
	// Remove all childNodes
	while (this.hasChildNodes())
		this.removeChild(this.firstChild);
		
	var r = this.ownerDocument.createRange();
	r.selectNodeContents(this);
	r.collapse(true);
	var df = r.createContextualFragment(str);
	this.appendChild(df);
	
	return str;
}

function init() {
	var theDiv = document.getElementById("theDiv");
	var innerHTML = 'generated';
	   innerHTML += '<button id="theBut" 
style="position:absolute;top:0;left:0;" onclick="dump(this);">push me</button>';
	   innerHTML += '<button id="theBu1" 
style="position:absolute;top:50;left:0;" onclick="dump(this);">push 
me</button>';
	theDiv.innerHTML = innerHTML;
	document.getElementById( "theBu1" ).setAttribute( "onclick" , 
"dump('ok');" );
}
function dump( str ) {
	document.getElementById("out").value+=str+"\n";
}
</script>
<body onload="init();">
	<div id="theDiv" 
style="position:absolute;top:50;left:10;background:silver;width:500;height:100;o
verflow:auto;">
	</div>
	<div 
style="position:absolute;top:155;left:10;background:silver;width:500;height:100;
overflow:auto;">
		must be...
		<button style="position:absolute;top:70;left:50;" 
onclick="dump(this);">push me</button>
		<button style="position:absolute;top:20;left:100;" 
onclick="dump(this);">push me</button>
	</div>
<textarea type="text" style="position:absolute;top:300;width:100%;height:100;" 
id="out"></textarea>
</body>
</html>
I (and Olivier Kurzweg <okurzweg@siticom.co.uk>) agree that the event problem
is the same as in bug 33577 so please attach (click the "Create a new
attachment" link above) a simplified testcase that shows the positioning
problem. (Ignoring event problem and changing subject to refelect the
positioning problem)

Thank you.

PS. In the future please file separate bugs on different problems, and if
possible please attach the testcase to the bug.
Summary: no events and position:absolute doesn't refer to the parent element → position:absolute doesn't refer to the parent element
savov@scopeland.bg - we need a simplified test case to get any further with this 
bug (assuming you can still see it).

Gerv
ok ,people
here comes more simply test

<html>
<title>where are the events?</title>
<script>

function init() {
	var src = '<button onclick="dump(\'oki... works\');">created 
Button</button>';
	var Elem  = document.body;
	var range = document.createRange();
	range.selectNodeContents( Elem );
	Elem.appendChild( range.createContextualFragment(src) );
}
</script>
<body >
  <button onclick="init();">click</button>
</body>
</html>

will this problem be solved soon?
Joki, here's one more for you, right?
Assignee: jst → joki
Confirming.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Okay so here's what's going on here.

For the event part I totally agree that this is a dupe of 33577.

For the div part the problem seems to be this.  The script first creates the 
elements using createContextFragment.  The style is assessed at that time and 
resolved relative to the document.  After that the fragment is appended to the 
div.  We do not re-resolve the style so the elements end up positioned relative 
to the doc, not the div, even though the parenting is set correctly.

I don't know what if anything we want to do with this.  I'll leave that to 
Johnny as my part is really the event part and I already have a bug for that.
Assignee: joki → jst
Mark, could you have a look at this? If not please reassign back to me or to
someone else that you think this belongs to. Thanks!
Assignee: jst → attinasi
OS: Windows NT → All
Hardware: PC → All
I think Joki's analysis is right-on. The problem is clearly that the style needs 
to be re-resolved after an element is essentially re-parented. Strangely, I 
thought that that was what happened, so it would take some digging to determine 
why it is not.

This does not seem like a critical problem for beta3 so I have to put it on the 
back burner for now, sorry. If somebody else has time to dig in deeper that 
woudl be great too.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(additional comment to the above attachement)
oops i forget to mentioned that the problem is again overflow:auto statement
the overflow property mess the things 'couse when i remove it everithing seem OK
Mass update of qa contact
QA Contact: gerardok → janc
Please, fix this bug ! In my mind it is absolutely necessary to support this 
feature because it is often necessary to position elements absolutely with 
respect to the parent element !
Assignee: attinasi → evaughan
Status: ASSIGNED → NEW
Component: DOM Level 1 → Layout
Summary: position:absolute doesn't refer to the parent element → overflow:scroll causes abs. pos. element's positioning to NOT be relative to the parent
Target Milestone: Future → ---
The problem here appears to be related to the scrollframe on the DIV. If the DIV
that contains the absolute positioned checkbox is given overflow:auto or
overflow:scroll (causing it to build a scrollframe) then the checkbox is not
positioned correctly. If instead it is given overflow:none or no overflow
property is set, the child checkbox positions correctly.

Sending over to Eric Vaughan since he has fixed several of these positioning
problems with scrollframes in the past, and 100-times faster than I can do it.
Also updating the summary...
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.
Keywords: testcase
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
->moz1.0
Target Milestone: mozilla0.9 → mozilla1.0
not my area, best guess is vladimire.
:)
QA Contact: janc → vladimire
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
The testcases now work correctly -- positioning is correct, events are correct.
 I bet one of roc's recent changes to overflow handling fixed this.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: