WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
112024
Sticky positioning is broken for table rows
https://bugs.webkit.org/show_bug.cgi?id=112024
Summary
Sticky positioning is broken for table rows
Jon Rimmer
Reported
2013-03-11 08:23:38 PDT
position: -webkit-sticky is not working for tr elements. It is still working for at least some others. See attached testcase. Testing info... Google Chrome: 27.0.1436.0 (Official Build 187216) canary OS: Windows WebKit: 537.33 (@145278) JavaScript: V8 3.17.9
Attachments
Simple testcase
(568 bytes, text/html)
2013-03-11 08:24 PDT
,
Jon Rimmer
no flags
Details
Patch
(14.49 KB, patch)
2014-01-28 12:07 PST
,
Viatcheslav Ostapenko
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Jon Rimmer
Comment 1
2013-03-11 08:24:09 PDT
Created
attachment 192475
[details]
Simple testcase
Viatcheslav Ostapenko
Comment 2
2014-01-28 12:07:06 PST
Created
attachment 222471
[details]
Patch
Simon Fraser (smfr)
Comment 3
2014-01-28 12:36:50 PST
Comment on
attachment 222471
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=222471&action=review
> Source/WebCore/rendering/RenderBox.cpp:3093 > + const RenderBlock* cb = containingBlock->isRenderBlock() ? toRenderBlock(containingBlock) : containingBlock->containingBlock();
It's pretty confusing that a parameter called "containingBlock" is not actually the containingBlock. Should we make the parameter a RenderBlock* and fix the callers?
Viatcheslav Ostapenko
Comment 4
2014-01-28 12:47:47 PST
Comment on
attachment 222471
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=222471&action=review
>> Source/WebCore/rendering/RenderBox.cpp:3093 >> + const RenderBlock* cb = containingBlock->isRenderBlock() ? toRenderBlock(containingBlock) : containingBlock->containingBlock(); > > It's pretty confusing that a parameter called "containingBlock" is not actually the containingBlock. Should we make the parameter a RenderBlock* and fix the callers?
It appears to be pretty big change, because there are other methods (like containingBlockLogicalWidthForPositioned) that have the same problem and they call containingBlockLogicalHeightForPositioned . Can it be done in another patch?
Simon Fraser (smfr)
Comment 5
2014-01-28 13:01:53 PST
Comment on
attachment 222471
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=222471&action=review
>>> Source/WebCore/rendering/RenderBox.cpp:3093 >>> + const RenderBlock* cb = containingBlock->isRenderBlock() ? toRenderBlock(containingBlock) : containingBlock->containingBlock(); >> >> It's pretty confusing that a parameter called "containingBlock" is not actually the containingBlock. Should we make the parameter a RenderBlock* and fix the callers? > > It appears to be pretty big change, because there are other methods (like containingBlockLogicalWidthForPositioned) that have the same problem and they call containingBlockLogicalHeightForPositioned . > Can it be done in another patch?
OK. Also in some rare cases containingBlock() can return nil; not sure if we need to handle that here.
Viatcheslav Ostapenko
Comment 6
2014-01-28 13:13:34 PST
(In reply to
comment #5
)
> (From update of
attachment 222471
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=222471&action=review
> > >>> Source/WebCore/rendering/RenderBox.cpp:3093 > >>> + const RenderBlock* cb = containingBlock->isRenderBlock() ? toRenderBlock(containingBlock) : containingBlock->containingBlock(); > >> > >> It's pretty confusing that a parameter called "containingBlock" is not actually the containingBlock. Should we make the parameter a RenderBlock* and fix the callers? > > > > It appears to be pretty big change, because there are other methods (like containingBlockLogicalWidthForPositioned) that have the same problem and they call containingBlockLogicalHeightForPositioned . > > Can it be done in another patch? > > OK. Also in some rare cases containingBlock() can return nil; not sure if we need to handle that here.
I have put ASSERT there and didn't manage to make it fire. Also, callers for containingBlockLogicalWidthForPositioned and containingBlockLogicalHeightForPositioned have this comment: // We don't use containingBlock(), since we may be positioned by an enclosing // relative positioned inline. Checking what I can do about this.
WebKit Commit Bot
Comment 7
2014-01-28 14:17:11 PST
Comment on
attachment 222471
[details]
Patch Clearing flags on attachment: 222471 Committed
r162960
: <
http://trac.webkit.org/changeset/162960
>
WebKit Commit Bot
Comment 8
2014-01-28 14:17:15 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug