Bug 53140 - CSS 2.1 failure: dynamic-top-change-005 fails
Summary: CSS 2.1 failure: dynamic-top-change-005 fails
Status: RESOLVED DUPLICATE of bug 69210
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Robert Hogan
Depends on: 68149 69210
Blocks: 47141
  Show dependency treegraph
Reported: 2011-01-25 16:07 PST by Simon Fraser (smfr)
Modified: 2012-02-19 02:58 PST (History)
4 users (show)

See Also:

Reduction (395 bytes, text/html)
2011-09-18 15:11 PDT, Robert Hogan
no flags Details
Easier to understand reduction (780 bytes, text/html)
2011-09-29 12:59 PDT, Robert Hogan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Simon Fraser (smfr) 2011-01-25 16:15:05 PST
Maybe we get containing block wrong for relpos inline inside relpos inline?
Comment 2 Simon Fraser (smfr) 2011-01-25 16:17:41 PST
We're also failing to re-layout on the dynamic change.
Comment 3 Simon Fraser (smfr) 2011-01-26 09:32:51 PST
Part of the issue is with top: inherit not causing layout when the inherited value changes.
Comment 4 Simon Fraser (smfr) 2011-01-26 09:33:58 PST
(In reply to comment #3)
> Part of the issue is with top: inherit not causing layout when the inherited value changes.

This issue seems fixed on TOT.
Comment 5 Robert Hogan 2011-09-18 15:11:13 PDT
Created attachment 107799 [details]

This is a reduction of the issue, though I'm not 100% sure it is an issue.

dynamic-top-change-005 expects a relatively positioned originally inlined block-display child of a relatively positioned inline parent to render relative to the parent. So in the case of the reduction, it should render 75px relative to the top of the view. Firefox does this, but WebKit and Opera render 25px relative to the top of the view.

The reason WebKit does this is because the parent and child are in fact sibling render layers rather than parent and child, which is a result I guess of handling a block inside an inline flow. 

So is this an wanted side-effect of the 'All in-flow children of an inline flow must be inlines.' rule, or is the test wrong-headed in the first place?
Comment 6 Robert Hogan 2011-09-18 15:34:10 PDT
It really does look like the test expects the relpos block to offset 50px from the inline parent rather than the nearest containing block, which is the 'grandparent'. Is that really the expected behaviour of a relatively positioned block?
Comment 7 Robert Hogan 2011-09-29 12:59:53 PDT
Created attachment 109192 [details]
Easier to understand reduction

This makes the issue (as I see it) easier to see - there is no red if the relpos inline block calculates its offset from the relpos inline parent.
Comment 8 Robert Hogan 2012-02-19 02:58:42 PST

*** This bug has been marked as a duplicate of bug 69210 ***