SVG graphic is not rendered completely

RESOLVED WORKSFORME

Status

()

Core
SVG
RESOLVED WORKSFORME
4 years ago
a year ago

People

(Reporter: marius.spix, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

4 years ago
Created attachment 8431579 [details]
screenshot1.png (Incorrect rendering with SeaMonkey)

User Agent: Mozilla/5.0 (X11; Linux) AppleWebKit/538.1 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/538.1 Midori/0.5

Steps to reproduce:

I have a SVG graphic which is not rendered completely


Actual results:

The graphic lacks some objects.


Expected results:

The graphic should be rendered completely.
(Reporter)

Comment 1

4 years ago
Created attachment 8431580 [details]
The vector graphic
(Reporter)

Comment 2

4 years ago
Created attachment 8431581 [details]
Correct rendering with Midori (Webkit GTK+)
(Reporter)

Comment 3

4 years ago
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
Build-Identifikator: 20140307232427

I reported this bug with Midori, because my Seamonkey always breaks when using the scrollbar (#833117)
(Reporter)

Updated

4 years ago
Attachment #8431579 - Attachment description: screenshot1.png → screenshot1.png (Incorrect rendering with SeaMonkey)
(Reporter)

Comment 4

4 years ago
It seems that SeaMonkey only uses one quarter of the canvas to paint the graphic (see screenshot 2)
(Reporter)

Comment 5

4 years ago
Created attachment 8431583 [details]
Screenshot 3: Seamonkey only uses 1/4 of the canvas for painting SVG graphics
Works for me. I tried the bugzilla attachment and it displayed completely.
(Reporter)

Comment 7

4 years ago
I hope, that could help:

www-client/seamonkey-2.24 was built with the following:
USE="alsa chatzilla crypt custom-optimization dbus gstreamer ipc jit libnotify roaming startup-notification system-cairo system-icu system-jpeg system-sqlite wifi -custom-cflags -debug -minimal -pulseaudio (-selinux)" LINGUAS="de -be -ca -cs -en_GB -es_AR -es_ES -fi -fr -gl -hu -it -ja -lt -nb_NO -nl -pl -pt_PT -ru -sk -sv_SE -tr -uk -zh_CN -zh_TW"
CFLAGS="-march=native -pipe -mno-avx"
CXXFLAGS="-march=native -pipe -mno-avx"

x11-libs/cairo-1.12.16 was built with the following:
USE="X glib opengl openvg svg xcb xlib-xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) (-gles2) -legacy-drivers (-qt4) -static-libs -valgrind"

Other Cairo applications like evince and gimp are working fine, however
Created attachment 8432550 [details]
SVG graphic not completely rendered in latest Nightly on Linux

Hi,

I can reproduce it on the latest Nightly (32.0a1 2014-06-02), Aurora (31.0a2 2014-06-02) and Beta (30.0 20140529161749) on Linux (Debian Sid) x86_64 using the vector graphic attached by the reporter: the graphic seems to be cut at the bottom (screenshot attached).
It happens also with clean profile and Safe Mode. In Safe Mode it seems slightly better: more graphic is showed, but still not all.

Let me know if you need more info/testing!


Cheers,
Francesca
Also, tentatively moving it to Core:SVG, feel free to move it back if that's not the right Product/Component.
Status: UNCONFIRMED → NEW
QA Whiteboard: [bugday-20140602]
Component: Untriaged → SVG
Ever confirmed: true
Product: Firefox → Core
Hardware: Other → x86_64
Version: unspecified → Trunk
(In reply to Francesca Ciceri [:madamezou] from comment #8)
> I can reproduce it on the latest Nightly (32.0a1 2014-06-02), Aurora (31.0a2
> 2014-06-02) and Beta (30.0 20140529161749) on Linux (Debian Sid) x86_64
> using the vector graphic attached by the reporter: the graphic seems to be
> cut at the bottom (screenshot attached).

Your screenshot shows something different from what the reporter's screenshot shows.

In your screenshot, the graphic is just clipped by the bottom of the Window.  Resizing the window makes the full graphic (e.g. the "VE" at the bottom)" show up.

This behavior is correct & expected (unless the content has a viewBox attribute to say what region should be scaled to fit the window, and there is no such attribute here). It should match the behavior of a similarly-sized window in other browsers / SVG viewers.

The reporter's original screenshot (attachment 8431579 [details]) is different -- it's got the "VE" clipped, without the window border being involved.

Like Robert in comment 6, this WORKSFORME on Linux.  Reporter, to reduce the number of variables in play: can you reproduce this in official Firefox builds (from http://getfirefox.com/ ) or Firefox nightly builds (from http://nightly.mozilla.org/ )?
Flags: needinfo?(marius.spix)
(I'm using latest a recent Firefox 64-bit nightly, BTW, with version/datestamp "32.0a1 (2014-06-01)" in Help|About Nightly)
(In reply to Daniel Holbert [:dholbert] from comment #10)
> 
> Your screenshot shows something different from what the reporter's
> screenshot shows.
> 
> In your screenshot, the graphic is just clipped by the bottom of the Window.
> Resizing the window makes the full graphic (e.g. the "VE" at the bottom)"
> show up.

Uhm, you're right: in full screen I get the full graphic.
Sorry for the noise, I quite misunderstood the problem here :/. I'm afraid that Core bugs are totally out of my depth ;).

Should I move it back from New to Unco?

Cheers,
Francesca
No worries. Yeah, I'll do that.
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Reporter)

Comment 14

4 years ago
Also does not work on another System with Beta 31.0 [Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0] I will attach a screenshot.
(Reporter)

Comment 15

4 years ago
Created attachment 8443588 [details]
Does not work with Beta 31 on Windows
Flags: needinfo?(marius.spix)
Do you have a retina display? It looks like Safari is incorrectly halving the size of the graphic which is why you can see it all. There's no bug here that I can see. Opera 12 displays the testcase exactly the same as Firefox.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
(Reporter)

Comment 17

4 years ago
(In reply to Robert Longson from comment #16)
> Do you have a retina display? It looks like Safari is incorrectly halving
> the size of the graphic which is why you can see it all. There's no bug here
> that I can see. Opera 12 displays the testcase exactly the same as Firefox.

The screenshot I made today (FF31/WinXP) is from a 12" Compaq Mini 110 with 1024x600px, this makes 99 PPI. The first screenshot (SM 2.24/Linux64) was made on a Thinkpad T430 (14" and 1366x768px = 115 PPI). Retina means a pixel density of over 300 PPI , which none of both devices have.
(Reporter)

Comment 18

4 years ago
Sorry, the Compaq mini is only 10.1" => 118 PPI, but how does this matter?
If the resolution is greater then you have more pixels in the y direction so you see more of the drawing. Using a viewBox would make it display resolution independent but your drawing doesn't use one of those.
(Reporter)

Comment 20

4 years ago
Is it possible that this bug is a revenant of #614649? I don't think that it is invalid at all.
Flags: needinfo?(longsonr)
bug 614949 is just about how we display images. This bug is invalid, the author probably needs to use a viewBox.
Flags: needinfo?(longsonr)
(Reporter)

Comment 22

4 years ago
I mean bug 614649, not bug 614949.
(Reporter)

Comment 23

4 years ago
But it seems that FF does have another behavior than Webkit. What does the SVG spec say, if there is not viewBox defined? The problem is that FF does crops the picture to 1/4 of the canvas. It should use the full available space when no viewBox is defined, as Webkit does.
Firefox doesn't crop the picture, it's just too big for the canvas.
(Reporter)

Comment 25

4 years ago
The graphic is not to big. There is enough space in the window.
Not on my machine and not in the Firefox screenshots. Or are you trying on SeaMonkey as those screenshots do look wrong, if so this needs to be a SeamMonkey bug and not CORE->SVG. Let's try it there as there's nothing wrong with this on Firefox.
Status: VERIFIED → REOPENED
Component: SVG → Tabbed Browser
Ever confirmed: true
Product: Core → SeaMonkey
Resolution: INVALID → ---
(Reporter)

Comment 27

4 years ago
This bug also occurs on FF Beta 31, so it is not only a Seamonkey issue.
(Reporter)

Comment 28

4 years ago
And it also occurs on Windows x86 (32Bit)
Component: Tabbed Browser → SVG
OS: Linux → All
Product: SeaMonkey → Core
Hardware: x86_64 → x86
It's not cut off for me on Windows x86 32 bit. It is smaller than Firefox 30 which is odd and may well be a bug.
Actually no it's not smaller, just me misremembering from all the screenshots.

So we're left with:

a) you've zoomed in.
b) you have some extension that's breaking things.
c) something about your hardware is strange.

Nobody else sees this unfortunately.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → WORKSFORME
Zooming in doesn't cut the screen off at 1/4 for me so it can't be a)

If you still want to pursue this then you could try http://mozilla.github.io/mozregression/ if we could get it down to a single changeset that's broken things for you then we might be able to see whether there's any possibility of recoding whatever change that is.
(Reporter)

Comment 32

4 years ago
(In reply to Robert Longson from comment #30)
> Actually no it's not smaller, just me misremembering from all the
> screenshots.
> 
> So we're left with:
> 
> a) you've zoomed in.
> b) you have some extension that's breaking things.
> c) something about your hardware is strange.
> 
> Nobody else sees this unfortunately.

a) I didn't zoom in.
b) It even happens in safe-mode
c) It happens on two completely different machines (Thinkpad T430 vs. Compaq Mini 


The SVG is created with InkScape and is rendered correctly with other browsers.

I will try mozregression now.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 33

4 years ago
I am stuck here ...


$ mozregression --bad=2014-06-22
No 'good' date specified, using 2009-01-01
Running nightly for 2011-09-27
Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2
011/09/2011-09-27-03-08-45-mozilla-central/firefox-9.0a1.en-US.win32.zip
===== Downloaded 100% =====
Installing nightly
Starting nightly (revision: 1f800c226837)
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry
', or 'exit' and press Enter): good
Running nightly for 2013-02-07
Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2
013/02/2013-02-07-03-09-36-mozilla-central/firefox-21.0a1.en-US.win32.zip
===== Downloaded 100% =====
Installing nightly
Starting nightly (revision: 04e13fc9dbff)
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry
', or 'exit' and press Enter): bad
Running nightly for 2012-06-02
Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2
012/06/2012-06-02-13-43-06-mozilla-central/firefox-15.0a1.en-US.win32.zip.asc
===== Downloaded 8668% =====
Installing nightly
Traceback (most recent call last):
  File "c:\mozilla-build\python\Scripts\mozregression-script.py", line 8, in <mo
dule>
    load_entry_point('mozregression==0.18', 'console_scripts', 'mozregression')(
)
  File "build\bdist.win32\egg\mozregression\regression.py", line 276, in cli
  File "build\bdist.win32\egg\mozregression\regression.py", line 182, in bisect_
nightlies
  File "build\bdist.win32\egg\mozregression\regression.py", line 185, in bisect_
nightlies
  File "build\bdist.win32\egg\mozregression\regression.py", line 167, in bisect_
nightlies
  File "build\bdist.win32\egg\mozregression\runnightly.py", line 281, in start
  File "build\bdist.win32\egg\mozregression\runnightly.py", line 278, in install

  File "build\bdist.win32\egg\mozregression\runnightly.py", line 114, in install

  File "c:\mozilla-build\python\lib\site-packages\mozinstall-1.10-py2.7.egg\mozi
nstall\mozinstall.py", line 110, in install
    raise InvalidSource(src + ' is not valid installer file.')
mozinstall.mozinstall.InvalidSource: C:\Dokumente und Einstellungen\silke\firefo
x-15.0a1.en-US.win32.zip.asc is not valid installer file.
I guess you'll have to do it manually.

Download nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (the directoy names contain dates and you want to do mozilla-inbound or mozilla-central) and then work out which is the most recent good build and the first bad build.

Then provide the built from text from about:buildconfig i.e. something like https://hg.mozilla.org/releases/mozilla-release/rev/529a45c94e5a for each.
Do reopen if you get a regression range. As nobody else can reporduce this effect we can't do anything without that.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → INCOMPLETE
(In reply to Robert Longson from comment #34)
> I guess you'll have to do it manually.
> 
> Download nightlies from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (the directoy names
> contain dates and you want to do mozilla-inbound or mozilla-central) and
> then work out which is the most recent good build and the first bad build.
> 
> Then provide the built from text from about:buildconfig i.e. something like
> https://hg.mozilla.org/releases/mozilla-release/rev/529a45c94e5a for each.

marius.spix@web.de:
That "built from" text can be found on the about:config page, and it is also present in the small .txt file which accompanies the (windows) .zip and .installer.exe, (Linux) .tar.bz2, or (Mac) .dmg on the ftp.mozilla.org server.

You can still try to bisect the regression range by manually downloading and installing a build approximately halfway between your "last good" and "first bad" ones, finding out on which side of the fence it sits, and repeating from there until you get two successive builds, one good and the other bad.
(Reporter)

Comment 37

a year ago
The bug does not occur in 45.6.0 on Linux64. So I think it can be closed.
Resolution: INCOMPLETE → WORKSFORME
That's good to hear - thanks for following up!
You need to log in before you can comment on or make changes to this bug.