Background images broken with hardware acceleration when replaced by js

VERIFIED FIXED

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: lemon_juice, Assigned: seth)

Tracking

({regression})

35 Branch
x86
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox35 wontfix, firefox36- verified, firefox37- verified, firefox38- verified)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
Build ID: 20150112201917

Steps to reproduce:

I can see a problem with one web site: http://www.rubinstein.pl/en - apparently this site uses some javascript to replace background images on its pages every few seconds and also when you resize the browser - I suppose this is to provide different sizes of images to various devices.


Actual results:

Very often, but not always, I am seeing strange artefacts with the background images - sometimes they don't show at all, sometimes only a portion of an image is visible, sometimes there are very thin vertical stripes on the sides of the browser, which look like parts of the image. Most easily these problems can be seen when resizing the browser - but not only - simply click on different links in the top menu, for example click on Events many times and resize the window from wide to very narrow and see how the script that replaces the background works.

Some screenshots - in all these cases you can see the background is non existent (black) or cut off to some extent:

https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/main1.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/main2.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/main3.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/main4.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/events1.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/events2.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/events-conferences1.jpg
https://dl.dropboxusercontent.com/u/13230070/screenshots/Fx-bg-bug/special-offers.jpg

The problems began in Firefox 35 - earlier versions work fine. The problem also happens in the latest nightly 2015-01-21 but the problem seems partially fixed there - all is fine if I do not resize the browser but the same background corruptions happen when I do resize.

The problem occurs only when hardware acceleration is on. I'm using Windows 32-bit with HD Radeon 6450 (ASUS EAH6450 Series). I've just updated to latest drivers but nothing has changed. I have no idea which other graphic cards are affected.

I've been able to track down when the problem started happening in the nightly releases, the regression window is:

2014-09-26-03-02-02-mozilla-central
2014-09-27-03-02-04-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-09-26+03%3A02%3A02&enddate=2014-09-27+03%3A02%3A04




Expected results:

Background images should be visible.

Comment 1

3 years ago
[Tracking Requested - why for this release]:
Status: UNCONFIRMED → NEW
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
tracking-firefox36: --- → ?
tracking-firefox37: --- → ?
tracking-firefox38: --- → ?
Component: Untriaged → Layout: View Rendering
Ever confirmed: true
Keywords: regression
Product: Firefox → Core

Comment 2

3 years ago
Regression window
Good
https://hg.mozilla.org/mozilla-central/rev/43ab820c7b68
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140926183438
Bad:
https://hg.mozilla.org/mozilla-central/rev/818f353b7aa6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140926185533
Pushlog
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43ab820c7b68&tochange=818f353b7aa6

Regressed by:
818f353b7aa6	Seth Fowler — Bug 1069369 - Remove all manual discarding during frame lookup. r=tn a=kwierso
Blocks: 1069369
Flags: needinfo?(seth)

Comment 3

3 years ago
looks like bug 1124543

Comment 4

3 years ago
(In reply to Alice0775 White from comment #3)
> looks like bug 1124543

oops, wrong bug #

looks like  bug 1124051

Updated

3 years ago
See Also: → bug 1124051
(Reporter)

Comment 5

3 years ago
Yes, it's similar and the same regression window applies. The only difference is that for bug 1124051 turning off HA doesn't help while with this one it does. But possibly the root of the problem is the same.

I can see the current Nightly has a partial fix for both bugs. The test page in bug 1124051 renders better than in Firefox 35 but still there's quite big white rectangular space that is not filled with the background image. I have to clear the cache and restart Nightly to reproduce the bug again.

Updated

3 years ago
See Also: → bug 1125789
Tracking until we understand the issue better.

Seth - Can you take this one?
tracking-firefox36: ? → +
tracking-firefox37: ? → +
tracking-firefox38: ? → +
(Assignee)

Comment 7

3 years ago
If this is the same bug as bug 1124051, then there are two problems:

- I can't reproduce it on Windows, OS X or Linux.

- We don't have a regression range for the problem on Nightly, which is different than the problem in 35 (which was fixed in 36).

The site linked in comment 0 in this bug won't load for me, so I can't check whether I might be able to reproduce the problem in this case.

Given these problems, it's not appropriate to assign this bug to anyone yet. We're still at the stage of gathering information.

lemon_juice, it'd be really helpful if you could post the graphics information in about:support here. It's quite possible that this issue is specific to particular hardware.

Also, lemon_juice or Alice0775 White or anyone else who can reproduce this right now, it'd be very helpful to know when this issue regressed again after (assuming it's the same as bug 1124051) it was fixed in Firefox 36. Knowing which patch introduced the current version of the problem that we see now on Nightly would be tremendously helpful.
Flags: needinfo?(seth) → needinfo?(michal-ok)
(Reporter)

Comment 8

3 years ago
(In reply to Seth Fowler [:seth] from comment #7)
> - We don't have a regression range for the problem on Nightly, which is
> different than the problem in 35 (which was fixed in 36).
I don't know what regression range is missing? I comment 0 I posted the regression range for this problem in Nightly.

> The site linked in comment 0 in this bug won't load for me, so I can't check
> whether I might be able to reproduce the problem in this case.
The site didn't load for me today, either. I think it was down for some time but it's up again so please try again.

> Also, lemon_juice or Alice0775 White or anyone else who can reproduce this
> right now, it'd be very helpful to know when this issue regressed again
> after (assuming it's the same as bug 1124051) it was fixed in Firefox 36.
> Knowing which patch introduced the current version of the problem that we
> see now on Nightly would be tremendously helpful.
I didn't know this problem regressed again - do you mean it appeared on Nightly, then was fixed and then appeared again? I know when it appeared on Nightly (see comment 0) and I also know it is fixed in 36.0b4 - which period on Nightly should we check - the old releases when Nightly was tagged 36.0x? I'm a bit lost here since I don't know which Nightly I should correlate 36.0b with.

The current known regression ranges appear to be the same for this bug and for bug 1124051 so it's likely this is the same problem. Now I know this (regarding both bugs) from my experience:

1. The bugs appeared on Nightly 2014-09-27-03-02-04-mozilla-central
2. The bugs are partially fixed on latest Nightly 2015-01-27
3. The bugs are completely fixed/non-existent in 36.0b4


And here is my graphics information:

Adapter Description	ASUS EAH6450 Series
Adapter Drivers	aticfx32 aticfx32 aticfx32 atiumdag atidxx32 atiumdva
Adapter RAM	1024
Device ID	0x6779
Direct2D Enabled	true
DirectWrite Enabled	true (6.1.7601.18245)
Driver Date	8-30-2013
Driver Version	13.152.0.0
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	047b1043
Vendor ID	0x1002
WebGL Renderer	Google Inc. -- ANGLE (ASUS EAH6450 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
Flags: needinfo?(michal-ok)
(Assignee)

Comment 9

3 years ago
(In reply to lemon_juice from comment #8)
> (In reply to Seth Fowler [:seth] from comment #7)
> > - We don't have a regression range for the problem on Nightly, which is
> > different than the problem in 35 (which was fixed in 36).
> I don't know what regression range is missing? I comment 0 I posted the
> regression range for this problem in Nightly.

Right - as per the discussion in bug 1124051, the bug associated with that regression range has been fixed. It's unfortunate that the same symptoms have appeared again, as it makes search for the new regression range more confusing.

> The site didn't load for me today, either. I think it was down for some time
> but it's up again so please try again.

I'll try again, indeed.

> I didn't know this problem regressed again - do you mean it appeared on
> Nightly, then was fixed and then appeared again?

Right, that is exactly what I mean. We have a new bug with the same symptoms as the old bug, but a different cause.

What we want to do is figure out when it reappeared *after* bug 1098958 landed. That happened in commit a5fcba591258 on Wed, 10 Dec 2014. To be conservative (because it sometimes takes a while for a new Nightly to get built), let's say that Friday, 12 Dec 2014 is the first Nightly that doesn't have the bug. Some Nightly after that date reintroduced the bug; if we can figure out which one, it'll make fixing it a lot easier.

> And here is my graphics information:

Thanks! This is very helpful.
Assignee: nobody → seth
status-firefox35: affected → wontfix
(Assignee)

Comment 10

3 years ago
(In reply to Seth Fowler [:seth] from comment #9)
> I'll try again, indeed.

I tried to reproduce this tonight, and while I could load the site, I couldn't reproduce the bug.

Alice0775 White suggested in bug 1124051 that network connection speed might be a factor, so I'll try slowing down my connection tomorrow and seeing if that helps.
(Reporter)

Comment 11

3 years ago
Yeah, it's tricky because it sometimes happens, sometimes not, but for me it does most of the time. The best method is to open http://www.rubinstein.pl/en/events in a wide browser window and then make it smaller gradually - new background images will be loaded and during the transitions the bug manifests most often. The images also change every few seconds so some patience is required. When you see black background or broken background for more than a few seconds on a fast connection it means you caught it.

But again - in this particular case the problems occur for me only with HWA so this may be quite peculiar to the type of my video card and it may happen you will not experience the problem.

From my observations this problem doesn't need slow connection to manifest.
(Assignee)

Updated

3 years ago
Depends on: 1130328

Comment 12

3 years ago
I noticed that the class of the div holding the slider with these images (third div under body), namely .bg, has position:fixed, which could indicate the problem to be related to bug 803703.
(Assignee)

Comment 13

3 years ago
This should be fixed by bug 1130328, which we are still hoping to get into 36.
Untracking since we are already tracking bug 1130328
tracking-firefox36: + → -
tracking-firefox37: + → -
tracking-firefox38: + → -
Verified fixed on Firefox 36, 37 and 38 as part of verification for bug 1130328.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
status-firefox36: affected → verified
status-firefox37: affected → verified
status-firefox38: affected → verified
You need to log in before you can comment on or make changes to this bug.