Twitter "private messages" window has a big graphic glitch

RESOLVED DUPLICATE of bug 1227210

Status

()

Core
Layout
RESOLVED DUPLICATE of bug 1227210
2 years ago
2 years ago

People

(Reporter: julienw, Unassigned)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox45 affected, firefox46 unaffected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8705063 [details]
capture

See attachment.

Happens on latest Aurora (build id: 20160106004003) but works fine in Nightly.
(Reporter)

Updated

2 years ago
status-firefox45: --- → affected
status-firefox46: --- → unaffected
(Reporter)

Updated

2 years ago
Attachment #8705063 - Attachment description: Capture d'√©cran de 2016-01-07 11:42:12.png → capture
I can reproduce on GNU/Linux too. Nical, Bas, does it ring a bell?
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(bas)
tracking-firefox45: --- → +
(Reporter)

Comment 2

2 years ago
I'm on Linux too, let's precise this until someone tries on Mac/Win.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Maybe related to bug 1225044 ?
Looks like a duplicate of bug 1235407
Guys, you confirm?
(In reply to Sylvestre Ledru [:sylvestre] from comment #4)
> Looks like a duplicate of bug 1235407
> Guys, you confirm?

I don't think so, that one's Windows only.

Interestingly, here we are invalidating properly (according to paint flashing) but drawing crap instead of the content we should be drawing. No amount invalidation caused by hovering the misrendered parts help. Scrolling the list renders fine but that causes a different layerization. As soon as you stop scrolling and get back to the original flattened layer tree, painting is busted again. I haven't looked at the display lists yet, but I guess there's some kind of clipping that is different when the scrolling part has its own layer from when it is in the same layer as the rest of the page. Maybe the push-group Pop-group stuff (in the cairo backend), Bas?
Flags: needinfo?(nical.bugzilla)
(In reply to Nicolas Silva [:nical] from comment #5)
> Maybe the push-group Pop-group stuff (in the cairo backend), Bas?

Actually, it reproduces also with skia as the drawing backend, and with the OpenGL compositor. It doesn't seem to reproduce on Windows (10, with D3D11 compositing and D2D1 drawing).
Doesn't reproduce either with cairo as the drawing backend on Windows.
The width of the "glitched" area on the left of the list seems to be always roughly equal to the distance between the edge of the window and the list itself (it holds true as you resize the window). A similar thing happens on the Y axis, somewhat less noticeable. Looks like something is being computed in the wrong coordinate system.
Bas says it could be bug 1227210 which we'd need to uplift.
(In reply to Nicolas Silva [:nical] from comment #9)
> Bas says it could be bug 1227210 which we'd need to uplift.

...aaaand confirmed. I asked for the uplift on the bug
Depends on: 1227210
Flags: needinfo?(bas)

Comment 11

2 years ago
Duping per comment 10
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1227210

Updated

2 years ago
tracking-firefox45: + → ---
You need to log in before you can comment on or make changes to this bug.