Closed Bug 1514653 Opened 6 years ago Closed 6 years ago

Media files display incorrectly on groupme.com since Firefox 63

Categories

(Core :: Web Painting, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla66
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- fixed

People

(Reporter: bgstandaert, Assigned: mikokm)

References

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: 1. Go to https://groupme.com/ (14 million visits/month according to SimilarWeb) and sign up for an account. 2. Create a new chat, and have someone send you a picture. 3. Open the conversation, and click on the picture to enlarge it. Actual results: The picture should display correctly, as it does in other browsers. Expected results: There are artifacts around the picture, and part of the picture is cut off (see attached screenshots). Doing anything to trigger a reflow (resizing the browser window, etc.) makes the picture display correctly again. Mozregression result: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=85f1c6e5ddac7792b327c05996f8bf27ed728d72&tochange=92bd3b2178623a036ea91990aa5570e039890ff4
Attached image incorrect.jpg (deleted) —
actual rendering, red squares are where personal information was redacted
Attached image correct.jpg (deleted) —
expected rendering
Thanks for the details report! Myko, it seems your patch in Bug 1462672 caused this regression, could you have a look please? Thanks
Blocks: 1462672
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mikokm)
Keywords: regression
Component: Untriaged → Web Painting
Product: Firefox → Core
Thank you for the report, I managed to reproduce this with Nightly.
Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Flags: needinfo?(mikokm)
Priority: -- → P1

This was a very tricky bug to find. Simplified version of the display list:

nsDisplayWrapList layer=a ref=x
  nsDisplayTransform layer=a ref=x

The bug is caused by parent item of the transform changing along with a reference frame.

nsDisplayTransform old-layer=none ref=y
  nsDisplayTransform old-layer=a ref=z

When this updated display list is processed, we flatten both the parent and child transform items, and select the same PaintedLayerData for them. Since the parent transform item is new, it does not have an old layer to recycle, so the selected PaintedLayerData will not get a layer set.

The problem arises when the child transform item recycles its old layer with its own referenceFrame, which instead should be the one that the parent transform item is using.

Pushed by mikokm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/f722c4dbd4cc Use the reference frame of the first flattened effect when recycling the layer r=mattwoodrow
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Any chance we could create an automated test for this regression?

Flags: needinfo?(mikokm)
Flags: in-testsuite?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Any chance we could create an automated test for this regression?

Yes, I managed to create a reftest for this.

Flags: needinfo?(mikokm)
Attachment #9037836 - Flags: approval-mozilla-beta?
Attachment #9037836 - Flags: approval-mozilla-beta?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: