From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; 0.8) Gecko/20010218 BuildID: 2001021812 When you enclose an absolutely positioned element, with "auto" top and left, within a relatively positioned element, the absolutely positioned element doesn't appear anywhere near the relatively positioned element Reproducible: Always Steps to Reproduce: You can download the file, http://fluffyland.cx/projects/webnote/test_content_with_note.html and display it under X-windows mozilla. I haven't tried to reproduce under windows. Actual Results: The step above pretty much describes the bug. Expected Results: The absolutely positioned element should have been displayed next to the relatively positioned element (from my reading of the CSS-P standard) The CSS-P standard seems a little vague about what should happen with the "auto" properties of an absolutely positioned element. I'd like it to appear above/next to content in the HTML file.

Pretty sure this is a dupe. Will come around for another pass later. Get setup for your attack run...oh sorry momentarly over come by Star Wars imagery.

OK... I've looked at the URL provided. It has <span> elements which are being positioned, which obviosly has no effect. Stephen Rosman, could you attach a testcase that actually demonstrates the bug?

I have to admit I was drunk when I submitted this bug but in the cold hard light of day it's still there and the URL does demonstrate it. (I just don't think I explained it well) From my reading of what the "auto" value of an absolutely positioned element is meant to do, it should place the "auto" positioned element at the position on the page that it was up when it came across the element, it should just float "above" the page at that point and not interrupt the flow of the document which is "underneath" it. Mozilla currently postions the element correctly vertically but horizontally it places the "auto" positioned element at the start of the line (the left-most extreme of the containing box) While I was trying to find a way around this, I tried putting the "auto" absolutely positioned element inside a relatively positioned element. Although it did appear to position itself correctly horizontally, it positioned itself approximately twice as far down the page (vertically) as it should have. (If you're wondering why I want to do this (or can offer a work- around) I want to build web-postit notes by having a proxy parse an html page and insert "layers" at specific points in a document where an editor may have a comment. Of course a pixel positioned layer won't work since a differently sized/platformed/font-sized web browser won't have a piece of text at the same place.)

Stephen, I'm attaching a screenshot of what I see on that page. The only positioned elements are the span containing "ACTblah?OR" and the span containing "blah?". Being spans the of course ignore positioning completely. Are we talking about the same page here?

Positioning applies to all elements, except generated content. However, the display property of an element with 'position:absolute' will be set to 'display'. http://www.w3.org/TR/REC-CSS2/visuren.html#q24 And I believe inline relatively positioned element can be a containing block for an absolutely positioned element, the difference being that the containing block is formed by the content edge rather than the padding edge. http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details However, what was puzzling me about the test URL was that the Abs Pos element appeared to be missing - all I was getting was the Rel Pos span. Then I noticed if I made the window large enough it did appear, but way down the page - nowhere near in the Rel Pos SPAN. So there seem to be two bugs here: 1. The Abs Pos element is only being rendered only if it is present in the window on load; if one has to scroll down to it, it will not be rendered. 2. And what seems to be the current bug - that the position of the Abs Pos element is wrong. What I notice with this is that the top position of the Abs Pos element is roughly twice what it should be, as if the offset of the Rel Pos element is being used twice to calculate where to render the Abs Pos element. This remains true no matter where one positions the Rel Pos element. The left position seems to have what may be the BODY margin added twice - I'm not sure. Example. The following attachment contains: <p>text<br>text<br>text<br>text</p> <p> <span class="container-red" onmouseover="alert('Rel Pos SPAN is here')">Rel Pos SPAN <span class="abspos-blue" onmouseover="alert('Abs Pos SPAN is here')">Abs Pos SPAN</span> </span> </p> with the following style: .container-red {position:relative; border:2px solid red;} .abspos-blue {position:absolute; background:#aaccdd;} I included the alerts on mouseover to also show that the Abs Pos element doesn't behave properly. Notice that the mouseover has no effect.

I've just noticed that my attached testcase behaves differently online - the ABs Pos element is absent from the start, and even on reload. But forcing a repaint by resizing the window will make it appear. BTW, I'm using build 20010505115 in Win98.

Changing QA contact

not table specific, reassigning to core owner.

Stephen, if you are trying to get a psot-it kind of effect, you could try using the title attribute, so when you mouseover, the pop up would display with the comment.

adding the css experts for some advice on this one

There's definitely something wrong here, probably in all the code Troy (?) wrote to deal with positioning inside of a relatively positioned inline element.

retargeting

.

This now mostly works, due to roc's checkin from bug 235778. There are still perhaps issues with the left/top: auto positioning. *** This bug has been marked as a duplicate of 135082 ***

This case is still not quite right; remaining issues are tracked in bug 5016

The failure succeeds, so to speak, on six out of seven browsers I run. It causes the seventh (NN4) to forget what font it was using (one of my favorites). I am running windows XP-home, and will check out windows NT next week.

(In reply to comment #18) > Created an attachment (id=154318) > Documents a reliable failure caused by <p style=margin-left:3mm> or <p > style=text-indent:3mm> (3mm or any other nonzero displacement) It goes away > after the </p>. > > The failure succeeds, so to speak, on six out of seven browsers I run. It > causes the seventh (NN4) to forget what font it was using (one of my > favorites). I am running windows XP-home, and will check out windows NT next > week. A note to myself: Item 1: Same things happen on windows NT. Correction: margin-left:# appears to be all right after all. No misalignments after either <p style=margin-left:#> or <a style=margin-left:#>. (#!=0) Item 2: Misalignment of some absolute displacements occurs after either <p style=text-indent:#> or <a style=text-indent:#>. Would that be an AHA? I don't know.