1903222 - Green or pink line (glitch) on some avif images android 32 bit only

Status: RESOLVED DUPLICATE of bug 1905842

(Core :: Graphics: ImageLib, defect, P2)

Description

[Anton]

Attachment: Screenshot_2024-06-18-20-45-57-080.jpg

User Agent: Mozilla/5.0 (Android 11; Mobile; rv:127.0) Gecko/127.0 Firefox/127.0

Steps to reproduce:

Open one of the following websites (happens in others too, but not all):

https://www.kmart.co.nz
https://www.kmart.com.au

Click on any category, every items photo has a pink line on the far right if the image, both in the gallery and the page specifically for the product.

Examples:
https://www.kmart.co.nz/category/home-and-living/home-and-living-latest-arrivals/
https://www.kmart.co.nz/product/white-multi-section-shelf-43363919/

Actual results:

Every items image has a pink line on the far right if the image, both in the gallery and the page specifically for the product.

Expected results:

No pink line, other browsers do not have it.

Comment 1

[Anton]

This bug also happens on the current Firefox Beta for Android, both with graphics acceleration forced off and forced on. If you open the effected images and there native resolution in a new tab the pink line disappears. My phone is quite low end but the SOC/GPU is very common still

SOC: MT6761V/WB
GPU: PowerVR Rogue GE8300
2GB RAM

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Fenix::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Anton]

This URL opens with the pink glitch/line down the side.

https://kmartau.mo.cloudinary.net/1bbacb5d-4d4f-4576-8089-7d0f9b7c49fa.jpg?tx=w_300,h_300,c_pad

But if I remove the end characters (they seem to resize it) it looks fine, no pink line.

https://kmartau.mo.cloudinary.net/1bbacb5d-4d4f-4576-8089-7d0f9b7c49fa.jpg

Comment 4

[Anton]

To clarify you can't just open the image in a new tab to make the pink line disappear, you need to remove those characters like I explained in the previous post.

Sorry I made that a bit confusing.

Comment 5

[Anton]

Has this been reported to developers? What shall I do?

Comment 6

[Chris Peterson [:cpeterson]]

Anton, thanks for reporting this bug! Your screenshot makes the problem easy to understand. Do you know if this bug is new in Firefox 127? Have you used kmart.co.nz in earlier Firefox versions?

I can reproduce the bug on my Moto G5 Plus, but not my Samsung Galaxy A32.

I don't know if that is due to the Moto G5 Plus's GPU (Adreno 506) or smaller screen size. Maybe the website doesn't need to resize the image on the Galaxy A32's larger screen?

Comment 7

[Ashley Hale [:ahale]]

Can you go to about:support in the address bar and tap the copy text to clipboard button (either one of them is fine) and paste into an attachment on this bug?

Comment 8

[Anton]

Attachment: about_support.txt

Comment 9

[Anton]

Attachment: Screenshot_2024-06-21-10-30-08-159.jpg

Comment 10

[Anton]

about:support says I'm using Nightly , I'm not though, I don't have it installed, I attached my settings > about page too.

I first noticed this glitch years ago at mitre10.co.nz but I can't remember if it's happened on every phone I've used since (with Firefox for Android.)

It doesn't happen on desktop Firefox on Windows or Linux.

( Just an FYI kmart.com.au is the third most visited shopping site in Australia. )

Comment 11

[Anton]

It's been happening on kmart.co.nz for at least two years. Sorry I can't be more specific.

Comment 12

[Anton]

What exactly is happening when you see ?tx=w_300 after an image like the address below? The server is resizing the image before it's sent to the user somehow, is it possible Firefox is putting a green or pink line on every image/server that does that?

https://example.com/image.jpg?tx=w_300

You can add it to any image url on kmart.co.nz or kmart.com.au and you get a smaller image with a pink line. While an image with a normal url has no issue.

Comment 13

[Anton]

Attachment: Screenshot_2024-06-22-18-24-55-101.jpg

Comment 14

[Anton]

Also happening on https://www.nzherald.co.nz/ to about half the photos.

If that helps narrow down the issue.

Comment 15

[Anton]

Attachment: Screenshot_2024-06-24-13-33-55-723.jpg

Comment 16

[Anton]

Almost all images on https://www.harveynorman.co.nz/

A thicker pink line too, I'm 90% sure this is new, it wasn't there a month ago (or previously) , perhaps a change the website has made though.

Comment 17

[Jamie Nicol [:jnicol]]

I tested this on a range of devices, and it reproduces on all arm32 devices I tried, but not arm64. But an arm32 build on a 64bit processor does also reproduce. So it's a bug in 32 bit builds, and not device specific.

Loading this url: https://kmartau.mo.cloudinary.net/1bbacb5d-4d4f-4576-8089-7d0f9b7c49fa.jpg?tx=w_300,h_300,c_pad, I traced the pixel data backwards and I printf'ed the value of the right-most pixel of the first row here, and got 255, 117, 255, 255 which is the pink colour.

So it seems the AVIF decoder is outputing the pink pixels in arm32 builds. Moving to ImageLib. Timothy, Andrew, any ideas why this might be happening?

Comment 18

[Jamie Nicol [:jnicol]]

Here's the relevant logs:

    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] Create Dav1dDecoder successfully
    [Child 20679: TaskController #1]: D/AVIFDecoder dav1d_send_data -> 0
    [Child 20679: TaskController #1]: D/AVIFDecoder dav1d_get_picture -> 0
    [Child 20679: TaskController #1]: D/AVIFDecoder seq_hdr.color_description_present: 1
    [Child 20679: TaskController #1]: W/AVIFDecoder Unspecified colour_primaries value specified in colr box or AV1 sequence header, using fallback value (1)
    [Child 20679: TaskController #1]: W/AVIFDecoder Unspecified transfer_characteristics value specified in colr box or AV1 sequence header, using fallback value (13)
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] DecoderDav1d->Decode() succeeds
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] decodedData.mColorRange: 1
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] Processing color profile
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] mInProfile a6abaaf0
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] calling gfx::ConvertYCbCrToRGB
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] calling SurfacePipeFactory::CreateSurfacePipe
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] writing to surface
    jamiedbg pixel at x=299: 255, 117, 255, 255
    [Child 20679: TaskController #1]: D/AVIFDecoder [this=bfe5bd60] writing to surface complete

I also tried setting image.avif.use-dav1d to false, but it crashes the content process

Comment 19

[Timothy Nikkel (:tnikkel)]

Attachment: 1bbacb5d-4d4f-4576-8089-7d0f9b7c49fa.avif

Comment 20

[Timothy Nikkel (:tnikkel)]

Interesting.

image.avif.use-dav1d=false seems to work on desktop. I wonder why not on mobile.

I tried 32bit windows, the image appears fine.

Reproduced on a 32bit phone.

Seems that we only use asm in dav1d if we are on x86, x86-64, or aarch64, but not 32 bit arm:

https://searchfox.org/mozilla-central/rev/9fcc11127fbfbdc88cbf37489dac90542e141c77/toolkit/moz.configure#887

Comment 21

[Bob Hood [:bhood]]

Assigning Tim for tracking.

Comment 22

[Timothy Nikkel (:tnikkel)]

Bumping priority down a notch, reasoning: only shows up on 32bit android, only on some images, the images are still visible, just a fringe of unwanted color on the side.

Comment 23

[Kelsey Gilbert [:jgilbert]]

Assigned P2/S3 so dropping from triage.

Comment 24

[Anton]

Another common site this happens on is screen rant.com , all the small images.

Comment 26

[Anton]

Attachment: Screenshot_2024-08-03-08-59-01-492.jpg

Comment 27

[Anton]

Why was the priority bumped down twice?

(Genuine question please don't delete my post again I am not trying to be rude.)

Comment 28

[Anton]

100s of millions of people have low end devices, most likely Android devices that this effects (32bit roms.)

Comment 29

[Timothy Nikkel (:tnikkel)]

This was only bumped down in priority once. Comment 23 was a bookkeeping change and affect prioritization.

I bumped down the priority and I explained my reasoning in comment 22 but I will expand upon it as a courtesy. As you observed P1 is the highest priority. I cannot justify this bug being the highest priority because it only affects 32 bit android (which account for less than 10% of our android users), which is also a subset of all users on all platforms, it only affects avif images (which have much less usage then jpg, png, gif, and webp), the bug does not prevent the users from seeing the image, there is just a color fringe (a bug that preventing a user from seeing content or performing some action would serve to increase the priority).

Your post wasn't deleted. It was tagged so that it is collapsed by default, it can be seen by clicking the plus beside it. It was tagged because it didn't add anything useful to the bug.

Comment 30

[Timothy Nikkel (:tnikkel)]

In my testing this seems to have been fixed recently on nightly with this fix range

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a6ca5a18b4a0f2cf3d2138705baecde938568671&tochange=12bd668f66103e727d3198e600cb25aa4ea8b6dc

Bug 1905842 would make sense. This will make it to release Firefox in september.

needinfo to confirm that bug 1905842 fixing this makes sense and that we didn't just get lucky with some code changes but the underlying problem might be still lurking.

Comment 31

[Timothy Nikkel (:tnikkel)]

Enabling asm for arm 32 for dav1d is bug 1912557

Comment 33

[Timothy Nikkel (:tnikkel)]

I'm just going to mark this as a duplicate of the bug that fixed this. Assuming this wasn't an accidental fix with a bug still lingering, but rather an intentional fix the libyuv.