31278 2009-11-09 16:39:38 -0800 ASSERTION FAILURE: mode & UseTransforms in Assertion Failure in RenderSVGRoot::mapLocalToContainer 2026-04-01 08:56:32 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Mac (Intel) OS X 10.6 NEW http://intertwingly.net/blog/2009/11/05/Web3D InRadar P2 Normal --- 68117 41761 1 jingidy+wk simon.fraser ahmad.saleem792 ap dbates dino emilio galineau jchaffraix jeffrey+webkit mike mitz pdr sabouhallawa simon.fraser svillar webkit-bug-importer xan.lopez oldest_to_newest 161827 0 jingidy+wk 2009-11-09 16:39:38 -0800 Loading the URL gives the following assertion: ASSERTION FAILED: !fixed (WebCore/rendering/RenderSVGRoot.cpp:269 virtual void WebCore::RenderSVGRoot::mapLocalToContainer(WebCore::RenderBoxModelObject*, bool, bool, WebCore::TransformState&) const) 161837 1 dino 2009-11-09 16:56:02 -0800 Assertion comes because the page has position:fixed on the svg diagram used in the page footer. The page works fine in release builds, and the fixed position element is rendered correctly, so I'm not sure why the ASSERT is there. 161882 2 42819 dino 2009-11-09 18:02:58 -0800 Created attachment 42819 simple testcase Notice that the test has both position:fixed and a CSS transform on the svg element. Removing the ASSERT(!fixed) will cause the 2nd ASSERT to fire. Removing that will have the correct behaviour, but only when the CSS transform is not present. 161923 3 42843 simon.fraser 2009-11-09 19:31:12 -0800 Created attachment 42843 Testcase that shows that position:fixed on svg is busted 161926 4 42843 simon.fraser 2009-11-09 19:37:19 -0800 Comment on attachment 42843 Testcase that shows that position:fixed on svg is busted Never mind; that's currently expected with -webkit-transform and position:fixed (bug 31283). 161930 5 simon.fraser 2009-11-09 19:48:03 -0800 I think there are two issues here: 1. We haven't cleaned up the "fixed inside of transformed" codepath. I don' think the code in convertToLayerCoords() is doing the right thing there now by just calling localToAbsolute() ignoring transforms. 2. There needs to be some explicit hand-off code in the interface between SVG and HTML (in both directions), that maps the expectations of one into those of the other. 376164 6 mike 2011-03-30 03:20:09 -0700 Something similar is happening on YouTube HTML5 video embeds. For an example: disable Flash, visit http://www.trackosaurusrex.com/pblog/comments.php?y=11&m=03&entry=entry110329-122230 and click the play button in comment #3. Segfault in trunk rev 82358, webkitgtk/gtk3, caused by an assertion: ASSERTION FAILED: useTransforms Source/WebCore/rendering/svg/RenderSVGRoot.cpp(300) : virtual void WebCore::RenderSVGRoot::mapLocalToContainer(WebCore::RenderBoxModelObject*, bool, bool, WebCore::TransformState&) const 1008585 7 krit 2014-05-12 07:21:46 -0700 *** Bug 52961 has been marked as a duplicate of this bug. *** 1076563 8 248491 galineau 2015-03-11 21:59:38 -0700 Created attachment 248491 Patch update The ASSERT seems obsolete since RenderReplaced::mapLocalToContainer() does apply transforms. 1077473 9 248491 sabouhallawa 2015-03-16 11:09:11 -0700 Comment on attachment 248491 Patch update View in context: https://bugs.webkit.org/attachment.cgi?id=248491&action=review > Source/WebCore/rendering/svg/RenderSVGRoot.cpp:379 > ASSERT(mode & ~IsFixed); // We should have no fixed content in the SVG rendering tree. I think this comment is wrong. I think the assertion means that, the mode should have UseTransforms and/or ApplyContainerFlip. And if it does, it does not matter whether it has IsFixed or not. So it can be deleted if we decide to keep ASSERT(mode & UseTransforms) as it is right now. > Source/WebCore/rendering/svg/RenderSVGRoot.cpp:-380 > - ASSERT(mode & UseTransforms); // mapping a point through SVG w/o respecting trasnforms is useless. I do not think this is correct. The assertion is there to confirm that all the callers are passing the UseTransform flag always. If the caller does not pass this flag, the mapping from local to container will not include the css transformation. You can see the problem if apply your patch and open the attached test case and set a breakpoint in RenderSVGRoot::mapLocalToContainer() and wait for the following call stack. #0 0x0000000106ac3831 in WebCore::RenderSVGRoot::mapLocalToContainer(WebCore::RenderLayerModelObject const*, WebCore::TransformState&, unsigned int, bool*) const at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/svg/RenderSVGRoot.cpp:382 #1 0x0000000106a69f4a in WebCore::RenderObject::localToAbsolute(WebCore::FloatPoint const&, unsigned int) const at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/RenderObject.cpp:1585 #2 0x00000001069a91fe in WebCore::accumulateOffsetTowardsAncestor(WebCore::RenderLayer const*, WebCore::RenderLayer const*, WebCore::LayoutPoint&, WebCore::RenderLayer::ColumnOffsetAdjustment) at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/RenderLayer.cpp:2009 #3 0x00000001069a9061 in WebCore::RenderLayer::convertToLayerCoords(WebCore::RenderLayer const*, WebCore::LayoutPoint const&, WebCore::RenderLayer::ColumnOffsetAdjustment) const at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/RenderLayer.cpp:2125 #4 0x00000001069a2062 in WebCore::RenderLayer::offsetFromAncestor(WebCore::RenderLayer const*) const at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/RenderLayer.cpp:2131 #5 0x00000001069b6ca9 in WebCore::performOverlapTests(WTF::HashMap<WebCore::OverlapTestRequestClient*, WebCore::IntRect, WTF::PtrHash<WebCore::OverlapTestRequestClient*>, WTF::HashTraits<WebCore::OverlapTestRequestClient*>, WTF::HashTraits<WebCore::IntRect> >&, WebCore::RenderLayer const*, WebCore::RenderLayer const*) at /Volumes/Data/WebKit/OpenSource/Source/WebCore/rendering/RenderLayer.cpp:3818 Because mode is equal to 5, the mapLocalToContainer() does not apply the transformation. In WebCore::performOverlapTests(), if you look at the final value of boundingBox.location(), you will see that it is set to (8,42) which is the fixed value of the svg as if there were no css transform applied to it. The actual value should be (108,142) which is fixed position translated by the css transform. 1078041 10 galineau 2015-03-17 17:20:33 -0700 I clearly misunderstood what the flag meant. Thanks for the clarification. smfr points out the issue seems to be that WebRenderObject::WebRenderObject() does not set UseTransforms thus triggering the ASSERT. I am unsure why the former doesn't though. 1078048 11 simon.fraser 2015-03-17 17:29:20 -0700 WebRenderObject::WebRenderObject() is just stupid Safari-only debug code. We should make it a bit less stupid. 1274426 12 sabouhallawa 2017-02-08 10:30:27 -0800 *** Bug 120903 has been marked as a duplicate of this bug. *** 1274428 13 sabouhallawa 2017-02-08 10:30:55 -0800 *** Bug 104636 has been marked as a duplicate of this bug. *** 1274524 14 sabouhallawa 2017-02-08 13:07:25 -0800 <rdar://problem/14703176> 1530818 15 sabouhallawa 2019-04-26 15:00:15 -0700 <rdar://problem/45542171> 1532327 16 dbates 2019-05-02 10:28:00 -0700 Seen with debug WebKit in iPad simulator with WebKit r244742 Just hit ASSERT(mode & UseTransforms) today (05/02) when doing the following: 1. Visit <http://wordpress.com>. 2. Click login. 1532332 17 dbates 2019-05-02 10:36:48 -0700 (In reply to Daniel Bates from comment #16) > Seen with debug WebKit in iPad simulator with WebKit r244742 > > Just hit ASSERT(mode & UseTransforms) today (05/02) when doing the following: > > 1. Visit <http://wordpress.com>. > 2. Click login. Some debug notes when I hit this bug: (lldb) p mode (WebCore::MapCoordinatesFlags) $2 = 5 { size = 2 } { IsFixed = 1 ApplyContainerFlip = 4 } (lldb) p repaintContainer (const WebCore::RenderLayerModelObject *) $5 = 0x0000000000000000 (lldb) p transformState (WebCore::TransformState) $6 = { m_lastPlanarPoint = { x = 0.0, y = 0.0 } m_lastPlanarQuad = (m_p1 = { x = 0.0, y = 0.0 }, m_p2 = { x = 0.0, y = 0.0 }, m_p3 = { x = 0.0, y = 0.0 }, m_p4 = { x = 0.0, y = 0.0 }) m_lastPlanarSecondaryQuad = { __ptr_ = { std::__1::__compressed_pair_elem<WebCore::FloatQuad *, 0, false> = { __value_ = 0x0000000000000000 } } } m_accumulatedTransform = { __ptr_ = { std::__1::__compressed_pair_elem<WebCore::TransformationMatrix *, 0, false> = { __value_ = 0x0000000000000000 } } } m_accumulatedOffset = { width = 0px (0), height = 0px (0) } m_accumulatingTransform = false m_mapPoint = true m_mapQuad = false m_direction = ApplyTransformDirection } (lldb) p wasFixed (bool *) $7 = 0x0000000000000000 (lldb) In calling frame, RenderObject::localToAbsolute(): (lldb) p localPoint (const WebCore::FloatPoint) $8 = { x = 0.0, y = 0.0 } (lldb) p mode (WebCore::MapCoordinatesFlags) $9 = 1 { size = 1 } { IsFixed = 1 } 1532335 18 dbates 2019-05-02 10:39:20 -0700 (In reply to Daniel Bates from comment #17) > (In reply to Daniel Bates from comment #16) > > Seen with debug WebKit in iPad simulator with WebKit r244742 > > > > Just hit ASSERT(mode & UseTransforms) today (05/02) when doing the following: > > > > 1. Visit <http://wordpress.com>. > > 2. Click login. > > Some debug notes when I hit this bug: > > (lldb) p mode > (WebCore::MapCoordinatesFlags) $2 = 5 { size = 2 } { > IsFixed = 1 > ApplyContainerFlip = 4 > } > (lldb) p repaintContainer > (const WebCore::RenderLayerModelObject *) $5 = 0x0000000000000000 > (lldb) p transformState > (WebCore::TransformState) $6 = { > m_lastPlanarPoint = { x = 0.0, y = 0.0 } > m_lastPlanarQuad = (m_p1 = { x = 0.0, y = 0.0 }, m_p2 = { x = 0.0, y = 0.0 > }, m_p3 = { x = 0.0, y = 0.0 }, m_p4 = { x = 0.0, y = 0.0 }) > m_lastPlanarSecondaryQuad = { > __ptr_ = { > std::__1::__compressed_pair_elem<WebCore::FloatQuad *, 0, false> = { > __value_ = 0x0000000000000000 > } > } > } > m_accumulatedTransform = { > __ptr_ = { > std::__1::__compressed_pair_elem<WebCore::TransformationMatrix *, 0, > false> = { > __value_ = 0x0000000000000000 > } > } > } > m_accumulatedOffset = { width = 0px (0), height = 0px (0) } > m_accumulatingTransform = false > m_mapPoint = true > m_mapQuad = false > m_direction = ApplyTransformDirection > } > (lldb) p wasFixed > (bool *) $7 = 0x0000000000000000 > (lldb) > > In calling frame, RenderObject::localToAbsolute(): > > (lldb) p localPoint > (const WebCore::FloatPoint) $8 = { x = 0.0, y = 0.0 } > (lldb) p mode > (WebCore::MapCoordinatesFlags) $9 = 1 { size = 1 } { > IsFixed = 1 > } And the calling calling frame is WebCore::accumulateOffsetTowardsAncestor(WebCore::RenderLayer const*, WebCore::RenderLayer const*, WebCore::LayoutPoint&, WebCore::RenderLayer::ColumnOffsetAdjustment). And look what we have here a FIXME comment AND it only passes isFixed (see (*) line): [[ // FIXME: Positioning of out-of-flow(fixed, absolute) elements collected in a RenderFragmentedFlow // may need to be revisited in a future patch. // If the fixed renderer is inside a RenderFragmentedFlow, we should not compute location using localToAbsolute, // since localToAbsolute maps the coordinates from named flow to regions coordinates and regions can be // positioned in a completely different place in the viewport (RenderView). if (position == PositionType::Fixed && !fixedFragmentedFlowContainer && (!ancestorLayer || ancestorLayer == renderer.view().layer())) { // If the fixed layer's container is the root, just add in the offset of the view. We can obtain this by calling // localToAbsolute() on the RenderView. (*) FloatPoint absPos = renderer.localToAbsolute(FloatPoint(), IsFixed); location += LayoutSize(absPos.x(), absPos.y()); return ancestorLayer; } ]] <https://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayer.cpp?rev=244742#L2070> 1532337 19 dbates 2019-05-02 10:44:55 -0700 RenderSVGRoot::mapLocalToContainer() is the only implementation of mapLocalToContainer that asserts that UseTransforms is in mode. RenderSVGRoot::mapLocalToContainer() is too strict OR calling code is wrong. Calling code has FIXME that seems to acknowledge that it is wrong. So, it's probably wrong. 1578827 20 simon.fraser 2019-10-10 13:46:37 -0700 *** Bug 202803 has been marked as a duplicate of this bug. *** 1766714 21 430560 svillar 2021-06-04 02:15:13 -0700 Created attachment 430560 Minimal test Trying to revive a bit an old bug. I'm easily hitting this with automatically generated test cases. See for example the one I'm attaching. We should figure out what to do. I am no longer sure the ASSERT(mode & ^isFixed) is correct. Said mentioned that the comment is wrong but I think the ASSERT is what it's wrong here. I think it really wants to check !(mode & isFixed) because if I am not wrong mode was just a boolean and then it became an enum, so this is probably a leftover from that transition. WRT to the 2nd condition, I am not sure. It looks like Chromium deleted it when they enabled layer flattering. Not sure if that makes any sense in the WebKit context. 1921325 22 ahmad.saleem792 2022-12-22 01:48:06 -0800 Blink fixed similar assertion here - https://chromium.googlesource.com/chromium/src.git/+/1761ef2855918b3e54d974a7fa1a860d604d660f 2195918 23 karlcow 2026-04-01 08:56:32 -0700 *** Bug 32407 has been marked as a duplicate of this bug. *** 42819 2009-11-09 18:02:58 -0800 2009-11-09 18:02:58 -0800 simple testcase fixed-position.xhtml application/xhtml+xml 453 dino PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgo8aGVhZD4KICA8c3R5 bGUgdHlwZT0idGV4dC9jc3MiIG1lZGlhPSJzY3JlZW4iPgogICAgc3ZnIHsKICAgICAgcG9zaXRp b246IGZpeGVkOwogICAgICAtd2Via2l0LXRyYW5zZm9ybTogdHJhbnNsYXRlKDEwMHB4LCAxMDBw eCk7CiAgICB9CiAgPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KICA8cD4KICAgIFRoZXJlIHNob3Vs ZCBiZSBhbiBTVkcgY2lyY2xlIGJlbG93IHdpdGggZml4ZWQgcG9zaXRpb24uCiAgPC9wPgogIDxz dmcgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB2aWV3Qm94PSIwIDAgMTAwIDEw MCIgd2lkdGg9IjEwMHB4IiBoZWlnaHQ9IjEwMHB4Ij4KICAgIDxjaXJjbGUgY3g9IjUwIiBjeT0i NTAiIHI9IjQwIiBmaWxsPSJncmVlbiIvPgogIDwvc3ZnPgogIAo8L2JvZHk+CjwvaHRtbD4K 42843 2009-11-09 19:31:12 -0800 2009-11-09 19:37:19 -0800 Testcase that shows that position:fixed on svg is busted svg-fixed.xhtml application/xhtml+xml 491 simon.fraser PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgo8aGVhZD4KICA8c3R5 bGUgdHlwZT0idGV4dC9jc3MiIG1lZGlhPSJzY3JlZW4iPgogICAgYm9keSB7CiAgICAgIGhlaWdo dDogMTIwMHB4OwogICAgfQogICAgc3ZnIHsKICAgICAgcG9zaXRpb246IGZpeGVkOwogICAgICAt d2Via2l0LXRyYW5zZm9ybTogdHJhbnNsYXRlKDEwMHB4LCAxMDBweCk7CiAgICB9CiAgPC9zdHls ZT4KPC9oZWFkPgo8Ym9keT4KICA8cD4KICAgIFRoZXJlIHNob3VsZCBiZSBhbiBTVkcgY2lyY2xl IGJlbG93IHdpdGggZml4ZWQgcG9zaXRpb24uCiAgPC9wPgogIDxzdmcgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnLzIwMDAvc3ZnIiB2aWV3Qm94PSIwIDAgMTAwIDEwMCIgd2lkdGg9IjEwMHB4IiBo ZWlnaHQ9IjEwMHB4Ij4KICAgIDxjaXJjbGUgY3g9IjUwIiBjeT0iNTAiIHI9IjQwIiBmaWxsPSJn cmVlbiIvPgogIDwvc3ZnPgogIAo8L2JvZHk+CjwvaHRtbD4= 248491 2015-03-11 21:59:38 -0700 2015-03-11 21:59:38 -0700 Patch update fix-31278.patch text/plain 1527 galineau ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCA2NDBjY2Q3Li44YTA3NjlkIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUg QEAKKzIwMTUtMDMtMTEgIHN5bHZhaW4tZ2FsaW5lYXUgIDxnYWxpbmVhdUBhZG9iZS5jb20+CisK KyAgICAgICAgQXNzZXJ0aW9uIEZhaWx1cmUgaW4gUmVuZGVyU1ZHUm9vdDo6bWFwTG9jYWxUb0Nv bnRhaW5lcgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 MzEyNzgKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBO byBuZXcgdGVzdHMgKE9PUFMhKS4KKworICAgICAgICAqIHJlbmRlcmluZy9zdmcvUmVuZGVyU1ZH Um9vdC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpSZW5kZXJTVkdSb290OjptYXBMb2NhbFRvQ29u dGFpbmVyKTogUmVtb3ZlIG9ic29sZXRlIFVzZVRyYW5zZm9ybXMgQVNTRVJUCisKIDIwMTUtMDMt MDUgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2FsaWEuY29tPgogCiAgICAgICAg IFtTT1VQXSBDaGVjayBUTFMgZXJyb3JzIGFzIHNvb24gYXMgdGhleSBhcmUgc2V0IGluIHRoZSBT b3VwTWVzc2FnZQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL3N2Zy9SZW5k ZXJTVkdSb290LmNwcCBiL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9zdmcvUmVuZGVyU1ZHUm9v dC5jcHAKaW5kZXggMTZlNTJkMi4uOWZiNmVkNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUv cmVuZGVyaW5nL3N2Zy9SZW5kZXJTVkdSb290LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9yZW5k ZXJpbmcvc3ZnL1JlbmRlclNWR1Jvb3QuY3BwCkBAIC0zNzcsNyArMzc3LDYgQEAgdm9pZCBSZW5k ZXJTVkdSb290Ojpjb21wdXRlRmxvYXRSZWN0Rm9yUmVwYWludChjb25zdCBSZW5kZXJMYXllck1v ZGVsT2JqZWN0KiByZXAKIHZvaWQgUmVuZGVyU1ZHUm9vdDo6bWFwTG9jYWxUb0NvbnRhaW5lcihj b25zdCBSZW5kZXJMYXllck1vZGVsT2JqZWN0KiByZXBhaW50Q29udGFpbmVyLCBUcmFuc2Zvcm1T dGF0ZSYgdHJhbnNmb3JtU3RhdGUsIE1hcENvb3JkaW5hdGVzRmxhZ3MgbW9kZSwgYm9vbCogd2Fz Rml4ZWQpIGNvbnN0CiB7CiAgICAgQVNTRVJUKG1vZGUgJiB+SXNGaXhlZCk7IC8vIFdlIHNob3Vs ZCBoYXZlIG5vIGZpeGVkIGNvbnRlbnQgaW4gdGhlIFNWRyByZW5kZXJpbmcgdHJlZS4KLSAgICBB U1NFUlQobW9kZSAmIFVzZVRyYW5zZm9ybXMpOyAvLyBtYXBwaW5nIGEgcG9pbnQgdGhyb3VnaCBT Vkcgdy9vIHJlc3BlY3RpbmcgdHJhc25mb3JtcyBpcyB1c2VsZXNzLgogCiAgICAgUmVuZGVyUmVw bGFjZWQ6Om1hcExvY2FsVG9Db250YWluZXIocmVwYWludENvbnRhaW5lciwgdHJhbnNmb3JtU3Rh dGUsIG1vZGUgfCBBcHBseUNvbnRhaW5lckZsaXAsIHdhc0ZpeGVkKTsKIH0K 430560 2021-06-04 02:15:13 -0700 2021-06-04 02:15:13 -0700 Minimal test bug31278.html text/html 79 svillar PCFET0NUWVBFIGh0bWw+CjxzdHlsZT4KOmxhc3Qtb2YtdHlwZSB7cG9zaXRpb246IGZpeGVkO30K PC9zdHlsZT4KPHN2Zz4KPC9zdmc+Cg==