Closed Bug 1412244 Opened 7 years ago Closed 7 years ago

Blinking rendering with semi transparent page elements

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1412150
Tracking Status
firefox57 --- unaffected

People

(Reporter: mte90net, Unassigned)

Details

(Whiteboard: [gfx-noted])

Attachments

(4 files)

Using the latest Firefox nightly (2017-10-26) on that page https://www.meetup.com/RomaWordPress/photos/28269965/465649345/ the page start to blink when the mouse is moved on the page or is showed like on the screenshot.
Others report that using the 10-26 this is not happening but I cannot check right now.
Hi Daniele, could you attach the content of your about:support page to this bug? Thanks!
Flags: needinfo?(mte90net)
Whiteboard: [gfx-noted]
Attached file aboutsupport.txt
as asked :-)
Flags: needinfo?(mte90net)
I've been similar behaviour using gdocs while scrolling.
Happen also on facebook
I am also seeing this issue on our site https://inkbunny.net - most noticeably on pages for each image (click the thumbnails).

It seems to happen *after* I return to a rendered tab from another one, flipping back and forth between them - for a moment, everything is properly rendered, then in a *blink* the content area is rendered partially translucent - completely white parts are not translucent at all, while the blacker it gets, the more the background bleeds in. Like it's been inverse-multiplied?

At one point on the main page it seemed like a triangular portion of thumbnails (like, complete blocks, but in a triangular shape) had been repainted in this way, while the rest were fine. Maybe they were the ones which were repainted earlier/later?

It's not possible to reproduce consistently but it happens very frequently, seemingly related to whether a page has been partially "swapped out" and has to be re-rendered. I have a lot of tabs on this netbook so likely memory pressure is high. If I mouseover an element and it causes it to repaint, it does so correctly.

In terms of layout, we have a similar vertically scrolling content overlay on a fixed background.
The <html> element has overflow-y:scroll, margin/padding/border:0, width/height:100% and background:#333
The background image is on a <div> *inside* the <body> with z-index:-999, position:fixed, margin/padding:0, width/height:100%, and (e.g.) background:rgb(51, 51, 51) url("https://nl.ib.metapix.net/bg_themes78/lando7/1680x1050_daytime.jpg") no-repeat scroll center center / 100% auto

In addition images/thumbnails and usericons have filter:drop-shadow, in case it matters.

My hardware is AMD Brazos/Zacate E-350 with a relatively recent driver; I will attach support information.
Example of translucent background bleeding.
The issue appears to rely on the .elephant class on inkbunny.net having position:relative, in case it helps.

It does *not* appear to matter what the background image is on the #bgbox element, as long as it exists, e.g. background: #333 will cause the issue, just slightly less noticeably. The background-size: and other parts of background: appear irrelevant, as is the negative z-index. Similarly, it doesn't matter whether it's set on the element, or on #bgbox via CSS. But without a background: at all, there's no issue.
Ryan, duplicate of bug 1412150?
Flags: needinfo?(rhunt)
Yes this sounds exactly like bug 1412150.
Flags: needinfo?(rhunt)
(In reply to Ryan Hunt [:rhunt] from comment #10)
> Yes this sounds exactly like bug 1412150.

I forgot to add that I can't reproduce this issue locally on my laptop, so I can't test that it's for sure fixed by the patch in bug 1412150. But it matches the description exactly.
The issue appears to be resolved on the latest Nightly, per the fix merged for the bug mentioned above.
Oooor not. Just needed a little more time to show up again. I guess it hasn't quite finished working through mozilla-inbound yet. :-)

If there's a specific build to test I'd be glad to give it a spin, else I'll just wait until it's in.
(In reply to Laurence "GreenReaper" Parry from comment #13)
> Oooor not. Just needed a little more time to show up again. I guess it
> hasn't quite finished working through mozilla-inbound yet. :-)
> 
> If there's a specific build to test I'd be glad to give it a spin, else I'll
> just wait until it's in.

It just merged into central, should be in nightly soon. Or you can also try a windows build here [1] or the linux build here [2].

[1] https://queue.taskcluster.net/v1/task/Rqxpso13Q_yk5pR8tf0ECA/runs/0/artifacts/public/build/target.zip
[2] https://queue.taskcluster.net/v1/task/TB02J0jDTtCkipCkDGm6gw/runs/0/artifacts/public/build/target.tar.bz2
Thanks Ryan! I tried that build for a few hours and it... seems to work?

Always hard to prove a negative, but I turned the option to show painting on, and I can see it repainting the column containing a large image on a submission page shortly after switching back to the page, including the area which was previously letting the background show through.

The same happens on the originally-reported website - I can see images "popping back" as normal but there is no odd translucency when they do so.
Okay, I'll mark this as resolved duplicate. If it comes back, feel free to reopen.(In reply to Laurence "GreenReaper" Parry from comment #15)
> Thanks Ryan! I tried that build for a few hours and it... seems to work?
> 
> Always hard to prove a negative, but I turned the option to show painting
> on, and I can see it repainting the column containing a large image on a
> submission page shortly after switching back to the page, including the area
> which was previously letting the background show through.
> 
> The same happens on the originally-reported website - I can see images
> "popping back" as normal but there is no odd translucency when they do so.

Okay, I'll mark this as resolved duplicate then. If it comes back, feel free to reopen.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: