WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
151791
Clipping along compositing borders in svg-edit
https://bugs.webkit.org/show_bug.cgi?id=151791
Summary
Clipping along compositing borders in svg-edit
Philip Rogers
Reported
2015-12-02 20:48:42 PST
Created
attachment 266505
[details]
Screenshot of svg-edit The main content area in svg-edit is clipped in Safari 9 and nightly@
r192882
:
https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/svg-editor.html
Removing position:absolute on the #svgroot element seems to fix this. If compositing borders are turned on it's a bit more obvious where the clipping is. This does depend on your window size so you may need to resize it to see the bug.
Attachments
Screenshot of svg-edit
(313.39 KB, image/png)
2015-12-02 20:48 PST
,
Philip Rogers
no flags
Details
Maybe testcase
(546 bytes, text/html)
2015-12-03 22:00 PST
,
Simon Fraser (smfr)
no flags
Details
Patch
(6.40 KB, patch)
2015-12-06 21:16 PST
,
Simon Fraser (smfr)
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1
2015-12-03 18:18:07 PST
I think we have other bugs about SVG not being prepared to paint across multiple tiles sometimes.
Simon Fraser (smfr)
Comment 2
2015-12-03 18:21:43 PST
Would be nice to have a reduction.
Philip Rogers
Comment 3
2015-12-03 21:31:39 PST
Minimizing this reproduction ended up being very difficult but I got it in the end. <!DOCTYPE HTML> This test passes if there is a green rectangle with a blue border going all the way around.<br> <svg id="svgroot" width="640" height="480" overflow="visible"> <svg id="canvasBackground" x="0" y="0" width="640" height="480"> <rect width="100%" height="100%" fill="green" stroke-width="5" stroke="blue"/> </svg> </svg> <script> setTimeout(function() { canvasBackground.setAttribute('x', 640); canvasBackground.setAttribute('y', 240); svgroot.setAttribute('width', 1920); svgroot.setAttribute('height', 1440); }, 0); </script>
Simon Fraser (smfr)
Comment 4
2015-12-03 22:00:27 PST
Created
attachment 266599
[details]
Maybe testcase This testcase shows a repaint bug related to overflow=visible, but I'm not sure that's the same as the original, since a window resize doesn't fix the drawing of svg-edit.
Simon Fraser (smfr)
Comment 5
2015-12-04 21:52:10 PST
I think the problem is that InlineBoxes know nothing about the overflowing SVG. Here's the render tree in the small testcase: (R)elative/A(B)solute/Fi(X)ed/Stick(Y) positioned, (O)verflow clipping, (A)nonymous, (G)enerated, (F)loating, has(L)ayer, (C)omposited, (D)irty layout, Dirty (S)tyle ---G-LC -- RenderView (0.00, 0.00) (897.00, 465.00) renderer->(0x115ac92a0) -----L- -- HTML RenderBlock (0.00, 0.00) (897.00, 506.00) renderer->(0x115bdd730) node->(0x115b3f5b0) ------- --* BODY RenderBody (0.00, 0.00) (897.00, 506.00) renderer->(0x115bdd7e8) node->(0x115b3f6e8) ------- -- RootInlineBox (0.00, 488.00) (502.00, 18.00) (0x115b3a2a0) renderer->(0x115bdd7e8) ------- -- InlineBox (0.00, 0.00) (502.00, 502.00) (0x115b50e10) renderer->(0x115aef5e0) ------- -- svg RenderSVGRoot (0.00, 0.00) (502.00, 502.00) renderer->(0x115aef5e0) node->(0x115af08e8) ------- -- svg RenderSVGViewportContainer renderer->(0x115b91288) node->(0x115af0ab0) ------- -- rect RenderSVGRect renderer->(0x115a86108) node->(0x115ae1680) ------- -- #text RenderText renderer->(0x115be7ea0) node->(0x115b8a730) length->(1) "\n" After the rect in the SVG moves, the SVG bounds are actually 608x608, but line boxes only know about 502x502. So InlineFlowBox::paint() short-circuits, and we never paint the overflowing SVG.
Simon Fraser (smfr)
Comment 6
2015-12-04 22:25:18 PST
After the SVG changes, we run RenderSVGRoot::layout() which calls addVisualOverflow(), but we never hit InlineFlowBox::computeOverflow().
Simon Fraser (smfr)
Comment 7
2015-12-04 22:33:33 PST
That testcase is fixed by not treating the RenderSVGRoot as a layout boundary, if it has overflow. We need to trigger layout on the enclosing line boxes to recompute visual overflow. However, that doesn't fix svg-edit.
Simon Fraser (smfr)
Comment 8
2015-12-06 11:27:31 PST
Debugging svg-editor. We're bailing from RenderReplaced::shouldPaint() for the RenderSVGRoot: RenderSVGRoot 0x1242bf468 {svg} id="svgroot" (layout overflow 0,0 640x480) (visual overflow 0,0 641x481) at (0,0) size 1920x1440 clipped at (40,70) size 947x377 RenderSVGViewportContainer 0x1253fb288 {svg} id="canvasBackground" clipped at (40,70) size 947x377 RenderSVGRect 0x124ef4840 {rect} at (40,70) size 947x377 [stroke={[type=SOLID] [color=#000000]}] [fill={[type=SOLID] [color=#FFFFFF]}] [x=0.00] [y=0.00] [width=640.00] [height=480.00] What seems wrong is that its visual overflow is smaller than its size.
Simon Fraser (smfr)
Comment 9
2015-12-06 11:58:13 PST
The bug here is that RenderSVGRoot fails to call clearOverflow() before recomputing visual overflow, and in svg-editor it gets resize from 640x480 to 1920x1400, but retains stale visual overflow of 640x480.
Simon Fraser (smfr)
Comment 10
2015-12-06 21:16:31 PST
Created
attachment 266750
[details]
Patch
Radar WebKit Bug Importer
Comment 11
2015-12-06 21:17:12 PST
<
rdar://problem/23778937
>
WebKit Commit Bot
Comment 12
2015-12-06 22:27:26 PST
Comment on
attachment 266750
[details]
Patch Clearing flags on attachment: 266750 Committed
r193613
: <
http://trac.webkit.org/changeset/193613
>
WebKit Commit Bot
Comment 13
2015-12-06 22:27:29 PST
All reviewed patches have been landed. Closing bug.
Simon Fraser (smfr)
Comment 14
2015-12-08 09:55:23 PST
I filed
bug 151995
on the remaining issue.
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