[Webkit-unassigned] [Bug 11225] No scroll bars are displayed for standalone SVG image

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Sep 17 15:52:13 PDT 2008


------- Comment #22 from jhaas at chromium.org  2008-09-17 15:52 PDT -------
(In reply to comment #18)
> We have a function on SVGSVGElement called "isOutermostSVG" which handles the
> SVG in HTML case as well.  I think we should use that, and make it robust
> against !e->parentNode() if necessary.

The way I did it exactly parallels the way the same test is done a few lines
down. If we change one, we should change the other.

> Why is the setTimeout(0) necessary?

Because the value of window.scrollbars.visible isn't updated until after the
onload function is called. Without the setTimeout(), this test passes without
the patch.

> All files should have a newline at the end, or diff gets mad. :)  We wouldn't
> want to make diff mad...

Duly noted.

> Also, no need for this file to be executable:

I didn't tell SVN to do that, I wonder why it did?

> In general this looks good.  I'm not sure if SVG inside HTML should have
> scrollbars.  Maybe not?

Definitely not. 

> Maybe only when SVG is a root of a document?  What
> about the <img src="foo.svg"> case?  Seems we'll eventually need a way to turn
> this off in the <img> case.

Why? The <img> case works fine, the <img> case works even without the patch. In
that case, the <img> element is as large as the full extent of the SVG element
(or not, depending on its own style) and it's the HTML document that the
scrollbars control, not the SVG document.

> I was talking with hyatt on #webkit just now, and he suggested hacking:
> void FrameView::applyOverflowToViewport(RenderObject* o, ScrollbarMode& hMode,
> ScrollbarMode& vMode)

Hmm. I don't care for that approach. We're special-casing a style for SVG
elements, and it seems that the appropriate place to put that would be in the
style selector, which is where the existing special-casing already was.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list