[Tracking Requested - why for this release]:
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
looks like bug 1124543
(In reply to Alice0775 White from comment #3) > looks like bug 1124543 oops, wrong bug # looks like bug 1124051
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.
Tracking until we understand the issue better. Seth - Can you take this one?
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.
(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 22.214.171.124 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
(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.
(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.
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.
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.
This should be fixed by bug 1130328, which we are still hoping to get into 36.
Untracking since we are already tracking bug 1130328
Verified fixed on Firefox 36, 37 and 38 as part of verification for bug 1130328.