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)
Core
Layout
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>
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
savov@scopeland.bg - we need a simplified test case to get any further with this bug (assuming you can still see it). Gerv
Reporter | ||
Comment 3•24 years ago
|
||
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?
Comment 5•24 years ago
|
||
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
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
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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
Reporter | ||
Comment 11•24 years ago
|
||
Reporter | ||
Comment 12•24 years ago
|
||
(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
Comment 14•24 years ago
|
||
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 !
Updated•24 years ago
|
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 → ---
Comment 15•24 years ago
|
||
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...
Comment 16•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Comment 19•23 years ago
|
||
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
Comment 20•21 years ago
|
||
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.
Description
•