Nightly doesn't render SVG images to whole area

RESOLVED WORKSFORME

Status

()

P5
normal
RESOLVED WORKSFORME
6 years ago
3 years ago

People

(Reporter: nagase, Unassigned)

Tracking

({qawanted, regression, regressionwindow-wanted})

Trunk
ARM
Android
qawanted, regression, regressionwindow-wanted
Points:
---

Firefox Tracking Flags

(firefox19 unaffected, firefox20 affected, firefox21 affected, firefox22 affected, fennec+)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 723328 [details]
osm_tiles.svg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22

Steps to reproduce:

Open attached SVG file which include images with Nightly build.


Actual results:

Lower right area images are not rendered.


Expected results:

SVG images shoud be rendered to whole area.
(Reporter)

Comment 1

6 years ago
Created attachment 723329 [details]
Image with Firefox19 on Nexus7
(Reporter)

Comment 2

6 years ago
Created attachment 723330 [details]
Image with Nightly on Nexus7

Updated

6 years ago
Component: Graphics, Panning and Zooming → Graphics
Product: Firefox for Android → Core
tracking-fennec: --- → ?
Assignee: nobody → chrislord.net
tracking-fennec: ? → +

Comment 3

6 years ago
Apparently a regression, so adding qa flags - A window will definitely help me diagnose/fix this.
Keywords: qawanted, regression, regressionwindow-wanted
Adrian, can you help out here?
Flags: needinfo?(adrian.tamas)
OS: Mac OS X → Android
Hardware: x86 → ARM
Loading the attachment directly I can't reproduce the issue on Nightly 22.0a1 2013-03-12, Aurora 21.0a2 2013-03-12 or Firefox 20 beta 4 on the Samsung Glaxy Tab 2 7.0 (Android 4.1) but I am not sure that it is correctly supported in bugzilla.
I do not have a way to upload the image on a webserver to check it like that. Tried with dropbox but SVGs are not correctly supported. If you have access to a webserver that supports SVGs please uploaded somewhere and add the link so I can test it.
Flags: needinfo?(adrian.tamas)
I can repro this on a Nexus 7. Will investigate soon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: kbrosnan
status-firefox19: --- → unaffected
status-firefox20: --- → affected
status-firefox21: --- → affected
status-firefox22: --- → affected

Comment 7

6 years ago
Has this been tested after bug 850396 landed?
(Reporter)

Comment 8

6 years ago
I have tested with Nightly 22.0a1 (2013-03-15) on Nexus7, but the issue still occurred.

Comment 9

5 years ago
Worth noting that this is still an issue in current Nightly. I don't have the time to look into it right now, but it looks like perhaps the displayport calculated on load is incorrect. This may be fixed by fennec switching to the APZC (instead of the JPZC).
Assignee: chrislord.net → nobody
filter on [mass-p5]
Priority: -- → P5
Kevin, you had success reproducing this before. Is that still the case for you?
Flags: needinfo?(kbrosnan)
I am on PTO. Will look at it in November.
Yes I can reproduce this on a current Nightly and a Nexus 7 2012. This is the nexus 7 with a brownish back and a dimpled texture. If your Nexus 7 has a smooth black back then it is a 2013 version.
Flags: needinfo?(kbrosnan)
Kevin, I don't have access to that device. Any chance you can try hunting this down with mozregression?
Given that C++ PZC is about to land I would rather wait for that to be testable before trying to find a range for such an old bug. At best we will get a day range and building old fennec is a bit of a dark art as it requires very specific SDKs and NDKs.
Flags: needinfo?(kbrosnan)
I can't reproduce this on Nightly
Flags: needinfo?(kbrosnan)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.