1437663 - Github SVG preview of specific file gets cut and shows overly huge Github logo

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P1)

Description

[Tobias (:Tobbi) Markus]

Steps to reproduce:

1. Go to https://github.com/openclipart/Magirly/blob/master/Chirality%20With%20Hands.svg

2. See rendering issue.

Screenshot (Firefox): http://prntscr.com/idtpp9
Screenshot (Safari): http://prntscr.com/idtq3b

Comment 1

[Daniel Holbert [:dholbert]]

GitHub is providing explicit heights for us to use here, and we're honoring them.  And it's giving Chrome (and I imagine Safari) different, more-sensible, heights from the ones it gives Firefox.

In Firefox, I see this in DevTools:
  <div class="render-container [...]"... style="height: 84px;">
    <iframe class="render-viewer">
And there's a rule that gives .render-viewer "height:100%".  So we dutifully size the iframe to 84px tall. Meanwhile, inside the iframe, we get:
   <img src="data:image/svg+xml;base64,PD94..." height="300" width="7500">

So clearly, GitHub is giving us an <img> element that is too tall for its iframe.

On the other hand: in Chrome, GitHub serves content with "height:210px" on the render-container div, and they serve an <img> with "height=150". So that's why the image fits nicely there.

So it seems like there's some sniffing shenanigans going on here. Or perhaps they're using some API under the hood to come up with these sizes and that API is indeed broken in Firefox -- but it would require some reverse engineering to sort that out...

In the meantime, punting to Tech Evangelism, since it seems like we need to do some outreach to get GitHub to fix their sizing (or tell us what we're doing wrong that's making them serve us broken sizing).  Adam, maybe you can take a look?

Comment 2

[Mike Taylor [:miketaylr]]

Heya Bryan, is there someone over at GitHub you can point this at? Thanks!

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of markup served to chrome (with image shorter than container)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of markup served to firefox (with image taller than container)

Comment 5

[clarkbw]

(In reply to Mike Taylor [:miketaylr] (58 Regression Engineering Owner) from comment #2)
> Heya Bryan, is there someone over at GitHub you can point this at? Thanks!

Let's take a step back here Mike.  What is a Firefox?

Comment 6

[Vlad Filippov (:vladikoff)]

(In reply to clarkbw from comment #5)
> (In reply to Mike Taylor [:miketaylr] (58 Regression Engineering Owner) from
> comment #2)
> > Heya Bryan, is there someone over at GitHub you can point this at? Thanks!
> 
> Let's take a step back here Mike.  What is a Firefox?

According to Wikipedia (The "Free" Encyclopedia), F15 Firefox is a scooter by Malaguti. F15 Firefox is a 50 cc sport scooter with digital dash, liquid-cooled engine and twin disk brakes. Unlike the European version, for the US only limited number of units were imported and they featured limited numbers, certificates, and gold plated numbers in the Ben Bostrom US edition. Both the 50 and 150cc version have 13 inch wheels. Malaguti is an Italian scooter and motorcycle company based in San Lazzaro di Savena, founded by Antonino Malaguti in 1930. 

Designers at Malaguti use SVG graphics technology to design scooter parts and cannot preview them properly in their GitHubs. Please assist.

Comment 7

[mike.skalnik]

I originally filed https://bugzilla.mozilla.org/show_bug.cgi?id=1079486 because of this. 

The root of the problem is that GitHub tries to detect a reasonable size for the SVG in a hidden iframe. Chrome, Safari, and Edge all seem to give some reasonable values for the size, but Firefox has historically not done so. Digging through the history of this code, we've seen values less than 1px × 1px and larger than 2^32-1px × 2^32-1px. This has made calculations on our end rather tricky and error prone.

In this case, Chrome is providing us with that sizing so we use it. Firefox provides us with some unreasonable numbers, so we try to figure out the aspect ratio based on the (improperly in this case) based on the `viewbox` by which we can size the image with a 300px height. I'll file an issue to investigate why we're not determining the aspect ratio properly in this case. It'd also be ideal if Firefox could provide some more reasonable values for image sizes in hidden iframes.

You can work around this by giving your SVG an explicit `height` and `width`.

Comment 8

[clarkbw]

(In reply to Vlad Filippov (:vladikoff) from comment #6)
> Designers at Malaguti use SVG graphics technology to design scooter parts
> and cannot preview them properly in their GitHubs. Please assist.

Thanks Vlad! :-P

@skalnik filed bug 1079486 which duped into bug 548397 but the latter hasn't seen much progress.  If there was a fix for the underlying problem we could probably fix this up on our side.  That update would likely rip our some ugly Firefox only code that we don't want anyway.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Fwiw, I'm (slowly) rearchitecting stuff on the style system to be able to fix bug 548397. But it's not going to be a fast fix I'm any case, so finding a workaround for now would be neat.

Comment 10

[Sergiu Logigan [:sergiu]]

The issue is still reproducible on Windows 10 and Firefox nightly 63.

Comment 11

[Sergiu Logigan [:sergiu]]

Hey, Brian!
Can you please take another look at this one? We fixed the issue on our side, via https://bugzilla.mozilla.org/show_bug.cgi?id=548397.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

This is probably still blocked on bug 1471231... But yeah worth checking with GitHub.

Comment 13

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 14

[Raul Bucata]

The provided URL is not accessible (either because it is no longer valid, or because of permissions). But following: https://github.com/mozilianulb/testing/blob/main/sample_1280%C3%97853.svg, the SVG file is rendered as expected:

https://prnt.sc/7w_rpymJ7d77

Tobias, can you please confirm that the testing has been done according to your steps to reproduce? And is the issue reproducible on your side, still?

Tested with:

Browser / Version: Firefox Nightly 101.0a1 (2022-04-08) (64-bit) /Chrome Version 100.0.4896.75 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Comment 15

[Tobias (:Tobbi) Markus]

I haven't encountered this issue in a long time. I'd consider it fixed by now.

Comment 16

[Raul Bucata]

Thanks, Tobias, for confirming.