Closed
Bug 1427479
Opened 8 years ago
Closed 8 years ago
scrollbars don't show up inside of SVG-as-an-image
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: pbogdan104, Unassigned)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171226083017
Steps to reproduce:
I've created a data URI from a SVG string that contains a <foreignObject> tag with usual <div> tags. The data URI was created using `window.btoa(unescape(encodeURIComponent(svgString)))`. Then I've put the resulting data URI into the `src` attribute of an <img> tag.
Actual results:
The SVG rendering is displayed without any scrollbars for overflowed contents.
Expected results:
The SVG rendering should have scrollbars for elements with `overflow: auto`, this behaviour is working properly on WebKit based browsers and Edge.
Comment 1•8 years ago
|
||
Please use https://bugzilla.mozilla.org/attachment.cgi?bugid=1427479&action=enter to add your testcase.
Flags: needinfo?(pbogdan104)
| Reporter | ||
Comment 2•8 years ago
|
||
Please see here: https://jsbin.com/hizapakewe/1/edit?js,output
Comparing with Chrome for example, the scroll bar doesn't show and it affects the width of the rendered example.
Flags: needinfo?(pbogdan104)
Comment 3•8 years ago
|
||
Ah, OK I see now. Unfortunately SVG content in an image is not something we allow to have interactivity and scrollbars are an interactive element.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 4•8 years ago
|
||
I know that SVG images are not interactive. The bug was referring to the way the browser interprets overflow: scroll on elements. Instead of computing the image with the added width of the scroll bar, as Cheome does, it doesn’t take that into account at all. Please compare it with Chrome, where the scroll bar isn’t interactive but it still is rendered into the image.
Comment 5•8 years ago
|
||
Imagine that the image was a gif or png. Could you do this? If not then the rule is you can't do it in a SVG either.
Chrome may be slightly less strict about this in some cases but they are also trying to follow this fundamental rule too.
Comment 6•8 years ago
|
||
I don't think we're going to change anything here. overflow:scroll on an image is not supported because that's fundamentally asking for interactivity.
| Reporter | ||
Comment 7•8 years ago
|
||
I'm don't think I'm making myself clear enough, sorry. I'm only referring to how the image (being it gif, png, svg) is displayed in the browser. Not of interactivity at all. Through overflow:scroll I'm understanding only that the scroll bar is shown whether the content overflows or not and as a consequence it subtracts around 15px from the width of the content. As such, the content from the image isn't positioned the same as on Chrome (where it shows the scrollbar). Interactivity isn't the problem at all, only the width of the content.
Comment 8•8 years ago
|
||
(In reply to pbogdan104 from comment #2)
> Expected results:
>
> The SVG rendering should have scrollbars for elements with `overflow: auto`,
> this behaviour is working properly on WebKit based browsers and Edge.
I don't see any scrollbars in the testcase, when I view it under Safari-on-Mac or Chrome-on-Mac (where the system uses "overlay scrollbars").
So it sounds like our rendering (on *all* platforms) is at least consistent with the rendering of WebLKit/Blink browsers *on Mac*. Right?
Also: out of curiosity, what's your use-case for wanting non-functional scrollbars to show in images? (And do other browsers on Mac OS break your use-case just as much as Firefox does?)
(Note also that per bug 686581, we intentionally turn off some OS-styling of widgets like buttons and scrollbars when we're inside of an image, in order to avoid leaking more user data than we need to, because web developers can inspect the pixels of images via the <canvas> tag. This behavior you're reporting might not be a direct consequence of that, but it's perhaps related.)
| Reporter | ||
Comment 9•8 years ago
|
||
| Reporter | ||
Comment 10•8 years ago
|
||
| Reporter | ||
Comment 11•8 years ago
|
||
I have attached screens with the tested behaviour on my machine.
The consistency is the main issue for me, because I'm trying to get screenshots of a web page and display them in canvas, and the image is different in the two different browsers. The text content has more characters per line when the scroll bar isn't displayed, than it has when it is displayed.
From what I've tested, Safari is not working at all at displaying an image with <foreignObject> in canvas and Chrome is working as expected.
It might be related to the bug you mentioned, which would mean that Chrome needs to update to this behaviour as well.
Comment 12•8 years ago
|
||
I'm guessing you have an old version of Mac OS? I'm testing latest versions of Safari and Chrome on Mac OS, and both of them render your JSBin just fine, with no scrollbars on the Lorem Ipsum text. (Specifically, I'm using macOS 10.13.2 High Sierra, Chrome 63, and Safari 11.0.2.)
> The consistency is the main issue for me, because I'm trying to
> get screenshots of a web page and display them in canvas, and
> the image is different in the two different browsers.
To clarify, are you aiming for consistency (same rendering) *between different browsers*? Or consistency in the same browser between image & non-image contexts?
(I don't think you can really expect either of those entirely, though you can mostly expect internal consistency within a single browser if you disregard OS-themed widgets as noted at the end of comment 8.)
Summary: Rendering SVG as data URI in <img> src → scrollbars don't show up inside of SVG-as-an-image
| Reporter | ||
Comment 13•8 years ago
|
||
The main issue is between Chrome and FF.
Either way, I was aiming for both. In this case, the behaviour is the same either between browsers or between image and non-image. The scroll bar is not rendered and the number of text characters is not consistent. If it's a security issue, I'm not sure there is anything to do about it.
You need to log in
before you can comment on or make changes to this bug.
Description
•